Severity by source
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Local hypervisor-guest context (AV:L, PR:L), specific VPID/failed-entry ordering (AC:H), guest→host boundary (S:C); impact is stale-TLB corruption - availability-dominant (A:H) with weak integrity (I:L) and no clear confidentiality.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
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.
AnalysisAI
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stale guest translations active after a failed nested VM-Enter, causing KVM to miss a required TLB flush when L1 changes L2's VPID. Only hosts running Intel VMX with KVM nested virtualization explicitly enabled (nested=1) are affected; an attacker who already controls an L1 hypervisor guest vCPU with the ability to manipulate nested VMCS state could reassign L2's VPID, force a nested VM-Enter to fail, and then perform a successful VM-Enter so the missed flush leaves stale address translations in place. …
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 an Intel VMX host with KVM nested virtualization enabled (nested=1 / L1 running its own hypervisor with L2 guests using VPID). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a Linux kernel KVM nested-VMX (nVMX) correctness bug: KVM services queued local TLB flushes on full nested VM-Exits but not when a nested VM-Enter fails (e.g. … 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 | Apply the vendor-released kernel update for your branch: 5.15.221, 6.1.188, 6.6.157, 6.12.110, or 6.18.51 on the stable trees, or 7.2.5 / 7.3-rc1 on mainline, all of which include the fix that services local TLB flushes on failed nested VM-Enter (see the stable commits at https://git.kernel.org/stable/c/c0c66cd575e31218da6a7d104c6ef80b0830b60c, https://git.kernel.org/stable/c/1025b938dc439b75c720a568a855a13eeb245686, https://git.kernel.org/stable/c/312cdb6d8940827dea63a7a52fb714a5049f06d1, https://git.kernel.org/stable/c/f74fccdf4f7fb0780cd84944108d35f3d9dc46a7, https://git.kernel.org/stable/c/c43563e7518e65ec6ccaa6a65f84c5af5ca5d379, https://git.kernel.org/stable/c/62c3ee4c9f0e2efef5157358b3549e50ede96d73, and https://git.kernel.org/stable/c/05a0b701d1089fb57beeb8982f23c3bbafe0fa8b, with the NVD entry at https://nvd.nist.gov/vuln/detail/CVE-2026-89930). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all Linux hosts running Intel VT-x virtualization and determine which have KVM nested virtualization explicitly enabled (the kvm_intel nested=1 module parameter), prioritizing any multi-tenant or shared-tenancy platforms that grant L1 hypervisor guest privileges to external parties, and restrict administrative access to those L1 guests. …
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.
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
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM execu
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
EUVD-2026-80530
GHSA-j569-2qg3-pw8x