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

CVE-2026-89929 Overview

CVE-2026-89929 is a Linux kernel vulnerability in the KVM (Kernel-based Virtual Machine) nested virtualization subsystem. The flaw involves incorrect emulation of the INVVPID instruction on nested VMs (nVM). When KVM emulates INVVPID, it may execute the instruction on a physical CPU different from the one where the L2 guest last ran. This leaves stale Translation Lookaside Buffer (TLB) entries on the original physical CPU, breaking the guarantees that VPID (Virtual Processor Identifier) flushing is meant to provide. The result is a memory consistency issue in nested guests that can be triggered by a local attacker with the ability to run virtualization workloads.

Critical Impact
A local attacker running nested KVM guests can cause stale TLB entries to persist across CPU migrations, potentially leading to memory disclosure, integrity violations, or denial of service inside nested virtualization environments.

Affected Products

Linux kernel with KVM Intel (VMX) nested virtualization support
Systems using nested VM (L1 and L2 guest) configurations on Intel processors
Distributions shipping affected upstream kernel versions prior to the fix commits

Discovery Timeline

2026-09-16 - CVE-2026-89929 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-89929

Vulnerability Analysis

The vulnerability resides in KVM's nested VMX code path that emulates the INVVPID instruction. INVVPID invalidates TLB mappings tagged with a specific VPID, ensuring guests see a consistent virtual memory view after page table changes. KVM uses vpid02 on the physical CPU when L1 executes INVVPID against its L2 guest, after validating the operands.

The defect is a CPU affinity mismatch. KVM executes the physical INVVPID on whichever CPU L1 is currently running on, not on the CPU where the L2 guest (represented by vmcs02) last executed. If those CPUs differ, the invalidation targets a TLB that does not hold the stale entries, while the CPU that does hold them is never flushed.

Root Cause

The consider the following sequence: L2 runs on CPU #1 and exits to L1, so vmx->nested.vmcs02.cpu=1. L1 then migrates to CPU #2 and issues INVVPID. KVM emulates the instruction on CPU #2. L1 subsequently migrates back to CPU #1 and re-enters L2. Because vmcs02 never changed physical CPUs, vmx_vcpu_load_vmcs() does not raise KVM_REQ_TLB_FLUSH, and the stale TLB entries on CPU #1 remain active. This is a kernel-level race and locality bug in nested virtualization state tracking.

Attack Vector

Exploitation requires local, authenticated access with the ability to run a nested hypervisor (L1) hosting a guest (L2) on affected Linux KVM hosts. An attacker controlling scheduling in L1 can deliberately induce CPU migrations around INVVPID execution to force TLB inconsistencies in L2. The vulnerability carries a scope-changed impact because activity in a nested guest affects the underlying hypervisor's memory management guarantees. The fix ensures INVVPID is executed on the same physical CPU as vmcs02; otherwise KVM clears last_vpid=0 to force a full VPID flush on the next nested VM-Enter. See the Linux Kernel Commit 27bdeb5 for the reference fix.

// No verified exploit code is publicly available for CVE-2026-89929.
// Refer to the upstream commits for the corrective patches.

Detection Methods for CVE-2026-89929

Indicators of Compromise

Unexpected memory corruption, guest crashes, or paging inconsistencies inside L2 nested guests on Intel hosts.
Kernel log anomalies from KVM VMX subsystem correlated with vCPU migrations across physical CPUs.
Workloads that heavily exercise nested virtualization and frequently trigger INVVPID emulation paths.

Detection Strategies

Inventory Linux hosts running KVM with nested virtualization enabled (/sys/module/kvm_intel/parameters/nested set to Y or 1).
Compare running kernel versions against distribution advisories referencing the upstream commits listed in the CVE.
Audit VM configurations for L1 guests that expose VMX to L2, prioritizing multi-tenant hypervisor hosts.

Monitoring Recommendations

Monitor kernel updates for the affected KVM VMX code paths and track patch application across the fleet.
Alert on unusual guest kernel panics or TLB-related soft lockups on hosts running nested VMs.
Track host-level scheduler behavior for L1 vCPUs migrating frequently across physical CPUs during heavy INVVPID activity.

How to Mitigate CVE-2026-89929

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the CVE as soon as vendor-supported builds are available.
Restrict local access to hypervisor hosts and limit which users can create or run nested virtual machines.
Prioritize patching multi-tenant KVM hosts where untrusted workloads can run L1 hypervisors.

Patch Information

The fix is present in the upstream Linux kernel through commits 27bdeb5, 6d00e67, 9941850, and d03e721. The patch ensures INVVPID executes on the same physical CPU as vmcs02, and otherwise clears last_vpid=0 so a full VPID flush occurs on the next nested VM-Enter. Consult your Linux distribution's security advisories for backported package versions.

Workarounds

Disable nested virtualization on Intel KVM hosts where it is not required by unloading and reloading kvm_intel with nested=0.
Pin L1 guest vCPUs to specific physical CPUs to reduce cross-CPU migrations that trigger the race.
Avoid exposing nested virtualization to untrusted tenants until patched kernels are deployed.

bash

# Configuration example: disable KVM Intel nested virtualization
sudo modprobe -r kvm_intel
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-intel.conf
sudo modprobe kvm_intel
cat /sys/module/kvm_intel/parameters/nested