CVE-2026-89930 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Service local TLB flushes on failed nested VM-Enter
KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()).
However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says:
If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition.
The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case.
More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's Kernel-based Virtual Machine (KVM) subsystem, specifically within the nested virtualization implementation for Intel VT-x architecture known as nVMX, contained a logic flaw regarding the handling of Translation Lookaside Buffer flushes during failed nested VM-Enter operations. In standard operation, KVM correctly services local TLB flushes when a nested guest performs a full VM-Exit through functions such as __nested_vmx_vmexit(). However, the code previously neglected to perform these necessary flushes if a subsequent attempt by L1 hypervisor to enter its own virtual machine (L2) failed. This oversight created a scenario where stale memory translations could persist in the TLB despite changes to the Virtual Processor ID or other architectural state that should have invalidated those entries. The vulnerability stems from an incomplete synchronization between state updates and cache invalidation procedures during the complex transition phases of nested virtualization, where multiple layers of hypervisors interact with hardware features like VPID and MSR load lists.
The technical root cause lies in how KVM manages TLB coherence when transitioning execution contexts. According to Intel's Software Developer Manual, if any Model Specific Register is loaded in a manner that architecturally requires a TLB flush, the processor must update its translations so that it does not use cached entries from before the transition. While this requirement applies post-entry, the ambiguity regarding whether a failed entry should trigger immediate flushing led KVM to defer these operations only on successful transitions. Crucially, functions like nested_vmx_transition_tlb_flush() and MSR load list processing often update internal tracking variables such as last_vpid even when the VM-Enter ultimately fails due to invalid VMCS checks or other validation errors. By updating this state without flushing the TLB, KVM creates a discrepancy where the hypervisor believes it has switched contexts but the hardware still holds old mappings associated with previous VPID values. This mismatch violates the principle of least privilege and memory isolation required in virtualized environments.
The operational impact of this vulnerability is significant for systems running nested virtualization workloads. If an L1 hypervisor modifies the configuration for its guest, such as changing the assigned VPID or loading MSRs that imply context switches, and then encounters a failure during VM-Enter followed by a successful entry later, the TLB may retain stale entries from before the failed attempt. This can lead to memory corruption where code or data intended for one virtual machine is accessed incorrectly due to cached physical addresses pointing to wrong locations. In severe cases, this could allow an attacker controlling L2 to potentially read or write memory belonging to other guests or even the host system if isolation boundaries are compromised by stale translations. The risk is heightened in multi-tenant cloud environments where nested VMs might be used for testing or specialized workloads, as it undermines the fundamental security guarantee of virtualization that processes and data remain strictly isolated within their designated domains.
This issue aligns with CWE-20 Improper Input Validation, as the failure to properly handle state changes resulting from invalid inputs during VM entry leads to inconsistent system behavior. Furthermore, it relates to CWE-674 Uncontrolled Resource Consumption if the stale TLB entries cause excessive cache misses or unexpected memory access patterns that degrade performance unpredictably. From a threat modeling perspective using MITRE ATT&CK techniques, this flaw could facilitate T1059 Command and Scripting Interpreter abuse in nested environments by allowing lateral movement through shared resources due to incorrect isolation boundaries, although direct exploitation requires specific timing and control over the L1 hypervisor's actions. The vulnerability highlights the complexity of maintaining hardware-software consistency in deep virtualization stacks where multiple abstraction layers must synchronize their state accurately under all execution paths including error conditions.
To mitigate this risk, it is essential that KVM services local TLB flushes not only on successful nested VM-Exits but also when a nested VM-Enter fails after having queued or triggered potential flush requirements. The fix involves ensuring that any update to tracking variables like last_vpid triggers an immediate architectural TLB invalidation regardless of the final outcome of the VM entry process. System administrators should apply kernel updates provided by their distribution vendors that include this patch for affected versions of Linux. Until patched, environments relying heavily on nested virtualization with dynamic VPID or MSR configurations are at higher risk and may consider restricting such workloads to isolated hosts where potential memory isolation breaches have limited blast radius. Regular auditing of KVM logs for frequent VM-Enter failures might also help identify systems experiencing this condition frequently, although the primary defense remains applying the vendor-supplied security patch that corrects the state synchronization logic in the nVMX implementation.