CVE-2026-89932: Linux Kernel KVM nVMX Privilege Escalation

CVE-2026-89932 Overview

CVE-2026-89932 is a vulnerability in the Linux kernel's Kernel-based Virtual Machine (KVM) nested VMX (nVMX) implementation. The flaw allows a nested guest to use stale Translation Lookaside Buffer (TLB) entries from a previous Virtual Processor Identifier (VPID) lifetime. The kernel fails to reset last_vpid when vpid02 is freed during VMXOFF, so if L1 executes VMXOFF followed by VMXON and KVM reuses a VPID with lingering TLB entries on the physical CPU, the nested guest may access memory mappings associated with a different vCPU or virtual machine.

Critical Impact
A local attacker in a virtualized environment can leverage stale TLB entries to compromise memory isolation between virtual machines, affecting confidentiality, integrity, and availability with a scope change across VM boundaries.

Affected Products

Linux kernel with KVM nested VMX (nVMX) support enabled
Intel VT-x host systems running nested virtualization
Distributions shipping vulnerable kernel versions with vpid02 allocation logic

Discovery Timeline

2026-09-16 - CVE-2026-89932 published to the National Vulnerability Database
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-89932

Vulnerability Analysis

The vulnerability resides in KVM's nested VMX handling of VPIDs. Intel VPID tags TLB entries with a processor identifier so entries from different virtual address spaces can coexist without full flushes. KVM tracks the previous VPID used on a vCPU through last_vpid, and nested_vmx_transition_tlb_flush() triggers a flush when the current VPID differs from last_vpid.

When the vCPU is created, last_vpid is initialized to 0. However, when L1 executes VMXOFF and vpid02 is freed, last_vpid is not reset. If L1 later executes VMXON and KVM allocates a new vpid02, the flush logic may compare against a stale last_vpid value that matches the newly allocated VPID. The TLB flush is skipped, and the nested guest inherits TLB entries from a previous VPID lifetime.

Root Cause

The root cause is missing state reset during VPID allocation. The fix sets last_vpid=0 when allocating vpid02, forcing nested_vmx_transition_tlb_flush() to detect a VPID change on the first VM-Enter after VMXON. Because vmcs12 cannot use VPID=0 when L1 enables VPID, the comparison always signals a change and a flush occurs.

Attack Vector

Exploitation requires local access with low privileges inside an L1 guest that can execute VMX instructions. An attacker running nested virtualization can trigger VMXOFF and VMXON cycles to influence VPID reuse. When the physical CPU retains TLB entries from a previously used VPID, the L2 guest may read or write memory mappings that belong to a different vCPU or virtual machine, breaking tenant isolation.

No verified public exploit code is available. Technical details are documented across multiple upstream kernel commits, including 8b98d662ab24 and 26de0d2d9a8d.

Detection Methods for CVE-2026-89932

Indicators of Compromise

Unexpected memory corruption or data inconsistency inside nested L2 guests running on shared physical hosts
Anomalous VMXOFF followed by VMXON sequences from L1 guests observable through KVM tracepoints
Cross-VM data patterns appearing in nested guest workloads without corresponding legitimate access

Detection Strategies

Audit installed kernel versions across hypervisor hosts and compare against patched stable branches referenced in the upstream commits
Enable KVM tracepoints such as kvm_nested_vmenter and kvm_flush_remote_tlbs to monitor nested VM entry patterns and TLB flush behavior
Correlate guest-reported memory anomalies with host-side VPID allocation events from kvm_intel module logs

Monitoring Recommendations

Track kernel package versions on all virtualization hosts through configuration management inventory
Alert on hypervisor hosts running unpatched kernels that also enable nested=1 on the kvm_intel module
Log workload behavior of tenants performing frequent nested VMX transitions to identify abuse patterns

How to Mitigate CVE-2026-89932

Immediate Actions Required

Apply the upstream Linux kernel patches that set last_vpid=0 when allocating vpid02 on all affected hypervisor hosts
Prioritize patching multi-tenant virtualization hosts where untrusted workloads run nested guests
Restrict nested virtualization to trusted tenants until patched kernels are deployed across the fleet

Patch Information

The fix is available in multiple stable Linux kernel branches. Reference the upstream commits including 121991d15073, 22dfcc22c95e, 26de0d2d9a8d, 62604376c313, 8b98d662ab24, 8bc609999ec2, and f0772389413d. Apply the vendor-provided kernel update matching your distribution.

Workarounds

Disable nested virtualization by setting the kvm_intel module parameter nested=0 where the feature is not required for production workloads
Isolate untrusted tenants onto dedicated hosts to reduce cross-VM impact until patches are deployed
Avoid packing nested-VM workloads from different security domains onto the same physical CPU

bash

# Disable nested virtualization on Intel KVM hosts as a temporary workaround
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-intel.conf
sudo modprobe -r kvm_intel
sudo modprobe kvm_intel
cat /sys/module/kvm_intel/parameters/nested