EUVD-2026-80529
GHSA-78pj-hm8w-chf6
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Local guest vCPU (AV:L/PR:L), CPU-migration race raises AC to H, guest→host isolation break is S:C, but impact is DoS-dominant so C/I:L and A:H.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU
When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on.
For example, in the following scenario:
- L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1)
- L1 migrates to CPU #2 and executes INVVPID
- KVM executes INVVPID on CPU #2
- L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1)
The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH).
Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().
AnalysisAI
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM executes the L1 guest's INVVPID on whichever pCPU is currently active rather than on the pCPU where L2 last ran. When L1 migrates to another CPU, issues INVVPID, and then migrates back to the original CPU to resume L2, the stale VPID mappings on that original pCPU are never invalidated and vmx_vcpu_load_vmcs() does not request a KVM_REQ_TLB_FLUSH because vmcs02 never ran on a different pCPU. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | 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. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | 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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Vendor-released patches are available: upgrade to Linux 6.12.110, 6.18.51, or 7.2.5 (or take the fix in 7.3-rc1), applying the stable-tree commit for your branch (d03e721801ac54b9fdf05668aa0c069f07913b68, 27bdeb5fd19046ffba9ff234e92fe553eb2efb30, 9941850e8adf164d005dbd3774c4b79e91a3cb8e, or 6d00e67326d831e6e610933a3800712f4ffe6ec1; see https://git.kernel.org/stable/c/d03e721801ac54b9fdf05668aa0c069f07913b68 and the linked NVD entry https://nvd.nist.gov/vuln/detail/CVE-2026-89929). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all x86 Linux KVM hosts with nested virtualization enabled, confirm exposure to CVE-2026-89929, and apply the vendor-released kernel/KVM patch using the exact version specified in your Linux distribution's security advisory (Red Hat, Ubuntu, SUSE, etc.); if immediate patching is not possible, disable nested virtualization on affected hosts or restrict L1 guest control to trusted administrators. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stal
Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed f
Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations fo
Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range
A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with
The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access
Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the
Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on
Slab use-after-free in the Linux kernel's KVM x86 MMU lockless rmap aging path affects hosts running Linux 6.15 through
A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a local
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today