GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM nVMX: queued TLB flushes skipped when a nested VM-Enter fails, leaving stale VPID mappings

CVSS 9.3CVE-2026-89930Kernel, userspace & hypervisorcurated

Impact

KVM services queued local TLB flushes on full nested VM-Exits but not when a nested VM-Enter fails its VMCS checks. Because KVM still records the new VPID for L2 on the failed entry, an L1 hypervisor that changes L2's VPID, performs a failing entry and then a successful one can end up running L2 against TLB entries cached for the previous context. On an x86 GPU host that rents out nested-capable VMs, that is a stale-translation window inside a tenant's nested guest. The fix always performs the flush on failed entry.

Who can reach it

Local, from a guest running its own hypervisor (nested virtualization) on an Intel KVM host. Requires the ability to run a VM with nested VMX exposed; hosts that do not expose nested VMX are unaffected.

What to do

Deploy a stable kernel carrying the linked commits and reboot each host, draining or migrating VMs first. Turning off nested VMX exposure (kvm_intel nested=0) removes the exposure if a reboot window is far off, but that itself requires reloading the module. No fixed release numbers are given in the record.

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.