GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM nVMX: vpid02 is not flushed on first use after VMXOFF/VMXON, reusing another VM's TLB entries

CVSS 8.8CVE-2026-89932Kernel, userspace & hypervisorcurated

Impact

last_vpid is initialized to zero when a vCPU is created but was not reset when vpid02 was freed on VMXOFF. If L1 does VMXOFF then VMXON and runs a new L2, and KVM reuses a VPID that still has TLB entries on the physical CPU, the nested guest can run against translations belonging to a previous lifetime of that VPID - possibly a different vCPU or a different VM entirely. That is cross-VM address-translation reuse on a shared host, the kind of leak a multi-tenant GPU cloud cannot accept. This is a distinct bug from the INVVPID-on-the-wrong-CPU issue also fixed this cycle, with its own fix: set last_vpid=0 when allocating vpid02 so the first nested VM-Enter always detects a VPID change and flushes.

Who can reach it

Local, from an L1 guest with nested virtualization enabled on an x86 KVM host. The guest controls the VMXOFF/VMXON sequence; no host credentials are needed. Hosts that do not expose nested virt are unaffected.

What to do

Update to a kernel carrying the linked stable commits and reboot the hypervisor after evacuating guests. Disabling nested virtualization for tenant VMs is an effective interim mitigation.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.