Severity by source
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Local guest vCPU access (AV:L, PR:L), timing race lowers reliability (AC:H), guest-to-host crossing (S:C); impact is host instability (A:H) with at most bounded integrity (I:L) and no real confidentiality primitive (C:N).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry
A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario:
- vcpu A walks the PTs to translate VNCR
- before vcpu A is able to grab the MMU lock to insert the TLB,
vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA
- vcpu A inserts the TLB for something that is now invalid
This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed.
We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.
AnalysisAI
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed for a page-table mapping that another vCPU has just invalidated, so a guest can keep using a translation the host believes is gone, corrupting host state and potentially crashing the host. The flaw only affects arm64 hosts running KVM with nested virtualization (FEAT_NV2 / VNCR fixmap) enabled where an attacker already controls a guest with at least two concurrently executing vCPUs, and exploitation hinges on winning a narrow race window between invalidate_vncr_va() on one vCPU and a VNCR translation fault-in on another (one vCPU rewriting S1 page tables and issuing TLBI S1E2 while the other is mid-walk). …
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 arm64 host running KVM with nested virtualization support (FEAT_NV2 / VNCR fixmap path) enabled, and an attacker who already controls a guest with at least two concurrently-running vCPUs. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a genuine but low-real-world-priority host-availability bug, and the vendor CVSS of 9.3 materially over-states it. … 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 kernel updates: upgrade to Linux 7.2.5, 6.18.51 or 7.3-rc1 (or later on those branches), which include the fix commits d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd, 11ee3faab4f1755d126bead9f882e75a7a677860 and 2b7324f3a0c1072b9d578b8d42f199506753f26e (see https://git.kernel.org/stable/c/d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd and the EUVD advisory EUVD-2026-80516 / https://nvd.nist.gov/vuln/detail/CVE-2026-89916). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory every arm64 host running KVM and confirm which of them have nested virtualization (FEAT_NV2/VNCR) enabled, since hosts without nested virtualization are not in scope, and flag any multi-tenant or nested-virtualization platform as the priority remediation group. …
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
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-80516
GHSA-5p99-rg43-px7f