Linux Kernel KVM EUVD-2026-80529

Requires a KVM x86 host with nested virtualization enabled (nested=1 / VMX exposed to guests) and an L1 guest actively running an L2 guest that issues INVVPID. The attacker must control an L1 vCPU (PR:L, local) and induce cross-physical-CPU migration timing so INVVPID is emulated on a different pCPU than the one L2 last ran on. Limiting factors: nested virtualization is a non-default, opt-in feature; exploitation depends on a narrow scheduling/migration race that is hard to control deterministically; and the primary effect is TLB corruption/instability rather than a clean data-exfiltration or code-execution primitive. Hosts without nested virt are unaffected.

This is a Linux kernel KVM nested-VMX (nVMX) correctness bug, not a memory-safety flaw: when emulating the L1 guest's INVVPID, KVM runs INVVPID on whatever physical CPU is current rather than the pCPU L2 last executed on, so after L1 migrates between CPUs the stale L2 TLB entries on the original pCPU are never invalidated. The vendor CVSS of 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) overstates real-world risk: AC:L is questionable because triggering the missed invalidation requires a precise vCPU/CPU-migration timing window (INVVPID on one pCPU, then L2 re-scheduled on the original pCPU before any flush), which is closer to AC:H, and C:H/I:H overstate a stale-TLB condition whose dominant outcome is guest/host instability and isolation breakage rather than reliable secret theft. No EPSS score, no CISA KEV listing, and no public PoC are present, so there is no evidence of active or imminent exploitation. The Tags field labels this 'Information Disclosure', which conflicts with the mechanism (a missed TLB flush is DoS/integrity-dominant); stale-TLB data exposure is theoretically possible but not the primary impact. Net: a legitimate isolation bug worth patching on nested-virtualization hosts, but a mid-tier priority, not an 8.8 emergency - realistically ~6.5.

A tenant with a nested-virtualization-enabled VM (L1) runs its own guest (L2) and issues INVVPID while deliberately migrating the L1 vCPU across host physical CPUs, causing KVM to invalidate the wrong pCPU's TLB and leave stale L2 translations resident. On subsequent nested VM-Enter the L2 guest may consume stale/incorrect address translations, producing guest instability, host-side TLB corruption, or cross-context translation errors. No public exploit code is identified at time of analysis, and the required CPU-migration race makes reliable weaponization difficult.