CVE-2026-43214: Linux Kernel Privilege Escalation Flaw

CVE-2026-43214 Overview

CVE-2026-43214 is a Linux kernel vulnerability in the Kernel-based Virtual Machine (KVM) x86 subsystem. The flaw resides in __get_sregs2(), which reads Page Directory Pointer Table Registers (PDPTRs) without holding Sleepable Read-Copy-Update (SRCU) read-side protection. Reading PDPTRs can trigger access to guest memory through kvm_pdptr_read(), eventually reaching kvm_vcpu_gfn_to_memslot(), which dereferences memslots requiring kvm->srcu or kvm->slots_lock to be held. The issue was discovered by the Linux Verification Center (linuxtesting.org) using Syzkaller fuzzing.

Critical Impact

Improper RCU usage in KVM ioctl path produces lockdep warnings and risks unsafe memslot dereferences when only vcpu->mutex is held during PDPTR reads.

Affected Products

• Linux kernel x86 KVM subsystem (arch/x86/kvm/x86.c)
• Linux kernel 6.12.59 confirmed in the reported lockdep trace
• Distributions shipping affected stable kernels prior to the fix commits

Discovery Timeline

• 2026-05-06 - CVE-2026-43214 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43214

Vulnerability Analysis

The vulnerability is a missing-lock condition in the KVM x86 vCPU ioctl handler. When userspace invokes the KVM_GET_SREGS2 ioctl, the kernel calls __get_sregs2() to populate the special registers structure, including PDPTRs used for 32-bit Physical Address Extension (PAE) paging. The PDPTR read path can lazily reload values from guest memory, which requires walking the memslot array protected by SRCU.

At the call site, only vcpu->mutex is held. The memslot dereference path uses srcu_dereference_check() and expects either kvm->srcu or kvm->slots_lock. The mismatch causes a suspicious RCU usage warning from lockdep and exposes memslots to unsafe access without SRCU read-side protection.

Root Cause

The call chain kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() -> kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot() reaches __kvm_memslots() in include/linux/kvm_host.h:1062. That helper requires SRCU protection, but __get_sregs2() did not enter an SRCU read-side critical section before invoking PDPTR reads.

Attack Vector

A local user with permission to open /dev/kvm and issue ioctls on a vCPU file descriptor can trigger the path through KVM_GET_SREGS2. The Syzkaller reproducer issues kvm_vcpu_ioctl from an unprivileged process inside a virtualization-enabled host. The vulnerability manifests during normal vCPU register query operations on guests using PAE paging on AMD SVM hosts.

No synthetic exploit code is provided here. Refer to the upstream commits for the exact fix scope and call-site changes.

Detection Methods for CVE-2026-43214

Indicators of Compromise

• Kernel log entries containing WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot
• Stack traces referencing __get_sregs2, load_pdptrs, and svm_cache_reg in dmesg
• Lockdep messages citing include/linux/kvm_host.h:1062 with only &vcpu->mutex held

Detection Strategies

• Enable CONFIG_PROVE_RCU and CONFIG_LOCKDEP on test kernels to surface the warning during QA
• Audit running kernel versions against the patched stable releases referenced in git.kernel.org commits
• Monitor /dev/kvm ioctl activity from non-root processes invoking KVM_GET_SREGS2

Monitoring Recommendations

• Forward kernel ring buffer events to a centralized logging pipeline and alert on suspicious RCU usage strings
• Track kernel package versions across virtualization hosts and flag hosts running pre-patch builds
• Review host audit logs for unexpected processes opening /dev/kvm on production hypervisors

How to Mitigate CVE-2026-43214

Immediate Actions Required

• Apply the upstream stable kernel updates that add SRCU read-side protection in __get_sregs2()
• Restrict access to /dev/kvm to trusted users and virtualization service accounts only
• Rebuild and redeploy custom kernels using the fix commits referenced below

Patch Information

The upstream fix wraps PDPTR reads in __get_sregs2() with an SRCU read-side critical section so memslot dereferences occur under kvm->srcu. Stable backports are available across multiple kernel branches. See the patch commits: 57536ff0a6bd, 708e20c66b27, 95d848dc7e63, 9f2bfea51151, b33f8d816950, and f621ca24f9f4.

Workarounds

• Limit /dev/kvm permissions through udev rules so only the virtualization group can open the device
• Disable nested virtualization features that are not required by guest workloads
• Avoid running untrusted workloads with KVM ioctl access on hosts pending kernel updates

# Verify running kernel and patch presence
uname -r
grep -r "__get_sregs2" /sys/kernel/debug/tracing/ 2>/dev/null

# Restrict /dev/kvm to the kvm group only
ls -l /dev/kvm
sudo chown root:kvm /dev/kvm
sudo chmod 0660 /dev/kvm