CVE-2026-89930: Linux Kernel KVM Privilege Escalation Flaw

CVE-2026-89930 Overview

CVE-2026-89930 is a vulnerability in the Linux kernel's KVM nested VMX (nVMX) implementation. The Kernel-based Virtual Machine (KVM) subsystem fails to service local Translation Lookaside Buffer (TLB) flushes when a nested VM-Enter operation fails. When Virtual Machine Control Structure (VMCS) checks reject a nested VM-Enter inside nested_vmx_enter_non_root_mode(), queued TLB flushes are silently dropped. KVM still updates last_vpid in nested_vmx_transition_tlb_flush(), which desynchronizes VPID tracking from actual TLB state. A subsequent successful VM entry can then reuse stale cached translations belonging to a different guest VPID.

Critical Impact
A local guest operator on a hypervisor running nested virtualization can trigger use of stale TLB entries across L2 guest address spaces, breaking memory isolation between nested virtual machines.

Affected Products

Linux kernel with KVM Intel (nested VMX) support enabled
Hypervisor hosts running nested virtualization on Intel VT-x processors
Distributions shipping affected stable kernel branches prior to the referenced fix commits

Discovery Timeline

2026-09-16 - CVE-2026-89930 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89930

Vulnerability Analysis

The defect resides in KVM's nested VMX transition logic. On a full nested VM-Exit executed through __nested_vmx_vmexit(), KVM correctly services any pending local TLB flushes. On a failed nested VM-Enter, however, the same servicing path is skipped. This asymmetry is significant because KVM can queue a TLB flush during entry preparation for legitimate architectural reasons, including VPID being disabled for L2 or MSR load list entries that architecturally mandate a TLB flush per the Intel Software Developer Manual (SDM).

Compounding the issue, nested_vmx_transition_tlb_flush() updates the tracked last_vpid value used for L2 even when the VM entry ultimately fails. If L1 changes L2's VPID, triggers a failing VM entry, and then performs a successful VM entry, the last_vpid state advances while the physical TLB still holds translations from the prior VPID context. The processor may then satisfy address translations from cached entries that no longer correspond to the current guest mapping.

Root Cause

The root cause is a missed code path in KVM's TLB flush servicing. The cleanup logic for a failed nested_vmx_enter_non_root_mode() returns to L1 without invoking the local TLB flush service routine, while still committing the VPID bookkeeping change. This is a kernel-level state consistency bug in the virtualization subsystem.

Attack Vector

Exploitation requires local access to the hypervisor as an entity capable of driving nested VMX transitions, typically a compromised or malicious L1 guest kernel running its own L2 guests. The attacker constructs a nested VMCS that fails validation, updates the L2 VPID between attempts, and then executes a valid VM entry. The resulting TLB state can be leveraged to read or influence memory translations that should belong to a different nested guest context.

No verified public proof-of-concept is available. The fix is distributed across the upstream commits 05a0b701, 1025b938, 312cdb6d, 62c3ee4c, c0c66cd5, c43563e7, and f74fccdf on git.kernel.org.

Detection Methods for CVE-2026-89930

Indicators of Compromise

Unexpected KVM warnings or kvm: vcpu messages in dmesg or /var/log/kern.log referencing nested VM entry failures on hosts running nested virtualization
Guest-reported memory corruption or inconsistent page contents inside L2 guests without corresponding host memory pressure events
Anomalous VPID churn observable through KVM tracepoints such as kvm_entry, kvm_exit, and kvm_nested_vmenter_failed

Detection Strategies

Inventory hypervisor hosts and verify whether kvm_intel is loaded with nested=1; only nested-enabled hosts are exposed
Compare running kernel versions against the fixed commits listed on git.kernel.org and against distribution security advisories
Enable KVM tracing (/sys/kernel/debug/tracing/events/kvm/) and audit rates of failed nested VM entries per VM

Monitoring Recommendations

Ingest dmesg, journald, and KVM tracepoint output into a centralized log platform for correlation across hypervisor fleets
Alert on new kernel modules loaded on virtualization hosts and on changes to the nested module parameter of kvm_intel
Track guest lifecycle events and correlate L2 guest crashes or reboots with host-side nested VM-Enter failure counters

How to Mitigate CVE-2026-89930

Immediate Actions Required

Apply the stable kernel updates that include the referenced commits on git.kernel.org and reboot affected hypervisor hosts
Where patching is delayed, disable nested virtualization on Intel hosts by reloading kvm_intel with nested=0
Restrict which tenants and workloads are permitted to run nested guests until patched kernels are deployed

Patch Information

The fix ensures KVM services local TLB flushes on failed nested VM-Enter, keeping TLB state consistent with updates to last_vpid. The change is present in the upstream commits 05a0b701d108, 1025b938dc43, 312cdb6d8940, 62c3ee4c9f0e, c0c66cd575e3, c43563e7518e, and f74fccdf4f7f. Consult the Linux kernel stable tree and your distribution's security tracker to confirm which stable branch carries the fix.

Workarounds

Set the kvm_intel module parameter nested=0 in /etc/modprobe.d/ and reload the module to disable nested VMX on the host
Migrate workloads that require nested virtualization onto already-patched hypervisor hosts and cordon unpatched nodes in orchestrators such as Kubernetes or OpenStack
Enforce least-privilege access to /dev/kvm so that only trusted service accounts can create virtual machines on affected hosts

bash

# Disable nested VMX on Intel hosts until patched kernels are deployed
echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/kvm-intel.conf
sudo rmmod kvm_intel
sudo modprobe kvm_intel
cat /sys/module/kvm_intel/parameters/nested   # expect: N or 0