CVE-2026-43214

What it actually does

This is a local Linux kernel KVM race-condition/RCU misuse issue in the x86 KVM path that reads guest PDPTR state through __get_sregs2(). The vulnerable code can reach guest-memory translation via kvm_vcpu_read_guest_page() and kvm_vcpu_gfn_to_memslot() while only holding vcpu->mutex, without the required KVM SRCU read-side lock or slots_lock. If a privileged local user with access to KVM interfaces can race virtual CPU register inspection against memory-slot changes, the kernel may dereference unstable KVM memslot state. Depending on timing and kernel configuration, this can cause kernel warnings or crashes and may create conditions for memory corruption, information disclosure, or local privilege escalation within the host kernel context.

Why it matters to the business

Systems that run KVM-based virtualization on affected Linux kernels are at risk from users or workloads that can access /dev/kvm, including local virtualization users, sandboxing frameworks, emulators, or containerized workloads granted KVM access. Successful exploitation could disrupt host availability, compromise confidentiality or integrity of the virtualization host, and potentially affect multiple guest workloads on the same host. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS activity, and has no public exploit maturity in the provided data, so broad opportunistic exploitation is currently less likely; however, the high CVSS impact and host-kernel boundary make it important for virtualization hosts and developer workstations using KVM.

How an attack unfolds

An attacker first obtains local code execution on a Linux system and access to the KVM device, typically through membership in a virtualization-related group, a VM management role, or a workload with /dev/kvm passed through. The attacker creates or controls a KVM virtual machine and vCPU, configures guest paging state so that KVM must read PDPTRs from guest memory, and repeatedly invokes the vCPU ioctl path that retrieves special register state, including the affected __get_sregs2() path. In parallel, the attacker changes or tears down guest memory slots to race the unprotected memslot dereference. The missing SRCU protection can allow KVM to observe inconsistent or stale memslot data while translating guest frame numbers. A reliable exploit would attempt to turn that race into a kernel crash, data exposure, or controlled memory corruption; a less reliable attempt may only trigger lockdep warnings, KVM errors, or host instability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream KVM x86 fix adding SRCU read-side protection around PDPTR reads in __get_sregs2(). No exact fixed package versions were provided, so use distribution vendor advisories and kernel changelogs for the relevant stable or long-term support branch. Prioritize KVM hosts, systems running QEMU/KVM, libvirt, virtualization platforms, Android emulators, CI runners, and developer systems where untrusted users can access /dev/kvm. If immediate patching is not possible, reduce exposure by restricting /dev/kvm access to trusted administrators only, removing unnecessary users from kvm-equivalent groups, disabling KVM for untrusted workloads, avoiding passthrough of /dev/kvm into containers, and isolating untrusted virtualization workloads onto patched hosts.

How to confirm the fix worked

Confirm that the running kernel includes the KVM x86 SRCU protection change for __get_sregs2() PDPTR reads, either by verifying the installed vendor security update, checking the kernel package changelog, or reviewing the source patch in arch/x86/kvm/x86.c. Validate runtime exposure by checking whether KVM is loaded and accessible, for example by confirming the presence and permissions of /dev/kvm and loaded kvm/kvm_intel/kvm_amd modules. After remediation, reboot into the fixed kernel and verify uname -r matches the patched package. For defense-in-depth validation, confirm that only trusted users or service accounts can access /dev/kvm and that containers or sandboxes do not receive the KVM device unless required. On debug or test systems, absence of the prior lockdep warning during KVM_GET_SREGS2-style testing can provide additional assurance, but production validation should rely on patch provenance rather than attempting to reproduce the race.

Typical attack path

1. Gain local execution on an affected Linux system that has KVM enabled.
2. Obtain permission to open /dev/kvm, such as through a virtualization user group, VM manager, emulator, or delegated KVM device access.
3. Create or control a KVM x86 virtual machine and vCPU.
4. Configure guest CPU paging/register state so PDPTR reads require KVM to access guest memory.
5. Repeatedly call the KVM vCPU ioctl path that retrieves special register state, reaching __get_sregs2().
6. Concurrently modify, remove, or churn KVM guest memory slots to race the unprotected memslot dereference.
7. Attempt to convert the race into host kernel memory corruption, information disclosure, privilege escalation, or denial of service.

How to detect it

Detection should focus on host-level evidence because exploitation is local and may not create network indicators. Review kernel logs, system journal, hypervisor logs, audit logs, and EDR telemetry for suspicious KVM ioctl activity followed by RCU warnings, kernel Oops messages, BUG reports, panics, or host instability. Look for repeated VM creation or vCPU register-query activity by unexpected local users, especially users recently granted access to /dev/kvm or processes running outside approved hypervisor management paths. Audit logs can help identify processes opening /dev/kvm and issuing heavy ioctl activity if audit rules are configured. Investigate crashes or warnings containing kvm_vcpu_gfn_to_memslot(), __get_sregs2(), load_pdptrs(), kvm_pdptr_read(), svm_cache_reg(), or kvm_vcpu_ioctl(), particularly when paired with memory-slot churn from QEMU, custom KVM harnesses, fuzzers, or unknown binaries. Because the provided intelligence indicates no KEV listing, no ransomware use, low EPSS, and no known public exploit maturity, absence of these artifacts does not prove safety; patch validation and access control review remain the primary assurance methods.

• suspicious RCU usage in kvm_vcpu_gfn_to_memslot
• include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage
• __kvm_memslots include/linux/kvm_host.h
• kvm_vcpu_gfn_to_memslot
• kvm_vcpu_read_guest_page
• load_pdptrs
• svm_cache_reg
• kvm_pdptr_read
• __get_sregs2
• kvm_arch_vcpu_ioctl
• kvm_vcpu_ioctl
• /dev/kvm
• WARNING: suspicious RCU usage
• rcu_dereference_check() usage
• KVM_GET_SREGS2

What your security team should do

• Inventory Linux systems with KVM enabled, especially virtualization hosts, CI runners, build workers, developer workstations, and container platforms that expose /dev/kvm.
• Prioritize patching systems where untrusted or semi-trusted users can create or control KVM virtual machines.
• Apply the vendor kernel update that contains the KVM x86 __get_sregs2() SRCU fix and reboot into the updated kernel.
• Temporarily restrict /dev/kvm permissions to trusted administrators or dedicated VM management services until patching is complete.
• Remove unnecessary users from groups that grant KVM access and audit service configurations that pass /dev/kvm into containers or sandboxes.
• Monitor kernel logs for KVM-related RCU warnings, BUG/Oops events, general protection faults, and crashes involving __get_sregs2(), kvm_vcpu_gfn_to_memslot(), load_pdptrs(), or kvm_vcpu_ioctl().
• Treat suspicious kernel crashes on KVM hosts with local untrusted users as potential exploitation attempts and preserve kernel logs, audit logs, process execution history, and VM management events for investigation.