Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local KVM access on arm64 NV host
-
DeliveryCreate and configure nested guest
-
ExploitTrigger VM destruction path
-
ExecutionFree shadow S2 structures still in use
-
PersistUse-after-free in host kernel memory
-
ImpactMemory corruption or privilege escalation
Vulnerability Assessment
| Exploitation Conditions | Requires an arm64 host running KVM with nested virtualization (NV) enabled - a non-default, recently-introduced feature - plus a local principal with privileges to create and destroy KVM guests (access to /dev/kvm). The trigger is the VM destruction / kvm_arch_flush_shadow_all path, where shadow stage-2 structures are freed while still referenceable by another part of the system. Limiting factors: no network vector (AV:L, local only), some privilege needed (PR:L), high attack complexity (AC:H) implying the lifetime/race window is hard to win reliably, no user interaction, and the vulnerable NV code path exists only in affected kernel versions with the feature compiled and active - so the overwhelming majority of Linux deployments are not exposed. |
| Impact | Signals are consistent and point to a genuine but low-urgency, low-reach issue. The CVSS vector (AV:L/AC:H/PR:L/UI:N/S:U, C:H/I:H/A:H, score 7.0) describes a locally-triggered, high-complexity flaw that still requires some privilege - not a remotely-reachable mass-exploitation target. EPSS agrees: 0.17% (6th percentile) indicates very low predicted exploitation probability. The vulnerability is NOT in CISA KEV, and no exploit code is present in the input (the only non-git references are NVD and a vuldb advisory page, which are catalog entries, not working PoCs). The vendor (Linux kernel) has published fixes, and the vuln.today Decision label is 'this_week' - meaningful but not emergency/act_now. The one tension worth stating: the CVSS vector and the description both agree on local access (AV:L), so there is no network-vs-local conflict, but the real-world attack surface is far narrower than 'Linux kernel' implies - the bug lives in KVM arm64 nested-virtualization (NV) teardown code, an experimental, rarely-enabled feature, so the headline 'Linux' footprint drastically overstates exposure. Net: a real correctness/lifetime bug worth patching on the next maintenance window, not a drop-everything incident. |
| Exploit ScenarioDerived | A local user with permission to create and destroy KVM guests on an arm64 host that has nested virtualization enabled repeatedly tears down VMs to trigger the premature freeing of shadow stage-2 structures while another part of the kernel still references them, aiming for a use-after-free in host kernel memory. Because the flaw is local, high-complexity, and requires the niche NV path, this is a realistic concern mainly for multi-tenant arm64 virtualization hosts rather than general systems. No public exploit code is present in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
A lifetime-management flaw in the Linux kernel's arm64 KVM nested-virtualization (nv) support frees shadow stage-2 structures from kvm_arch_flush_shadow_all() while other parts of the system may still hold references to that container, exposing the host kernel to use-after-free-style memory corruption, crash, or code execution in kernel context. Only arm64 hosts running KVM with nested virtualization active on an affected kernel are exposed - a non-default, recently introduced feature - and the assessed CVSS vector (AV:L/AC:H/PR:L) reflects a local attacker with privileges to create and destroy KVM guests and a narrow, hard-to-win lifetime window. No public exploit code or confirmed active exploitation was identified at time of analysis (EPSS 0.17%, 6th percentile), and vendor fixes are listed for 6.12.113, 6.18.56, 7.2.9 and 7.3-rc5.
RemediationAI
Vendor-released patch: update to Linux 6.12.113, 6.18.56, 7.2.9 or 7.3-rc5, or apply the corresponding stable commits 5bf1c9175e657b3c2dc1cf77403031ac7aadcf66, e5843f4effaa2ffac3e789ecd4456403564961d4, 876049f026b4dfaca0cc78ec81be0e639ca8525d and 22e82acec93a681071ed36f70eabe2d0c4e0bebd from the links at git.kernel.org/stable/c/ (details also at nvd.nist.gov/vuln/detail/CVE-2026-98440 and vuldb.com/vuln/421781). Because the fix is a teardown-ordering change rather than a toggleable condition, there is no simple configuration switch described in the supplied sources; the practical compensating control is to restrict access to /dev/kvm on arm64 hosts to trusted local principals only, accepting that this breaks unprivileged VM tooling and containers that expect KVM access, and to avoid running nested or untrusted guests on hosts that must remain on an unpatched kernel. Patching cadence is this_week per the priority decision label; no public exploit code has been identified, so no emergency out-of-band action is indicated for the general fleet.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
KVM/arm64 nested virtualization lets a guest hypervisor run its own stage-2 translation, which the host implements through "shadow" stage-2 (S2) page tables and per-MMU bookkeeping structures held in a global array of pointers. The vulnerable code path is the architected flush callback kvm_arch_flush_shadow_all(), whose contract covers invalidating page tables when shadow mappings must be dropped (for example on memslot changes); the upstream fix notes that freeing page tables there is legitimate but freeing the container structures is not, because other subsystems can still reference them after the flush. The CVE has no CWE assigned in the supplied data; the defect as described is a lifetime/dangling-reference class problem, not a bounds or input-validation bug, and the sources do not detail the exact interleaving that produces the stale reference. The remediation restructures teardown: separate destructors are invoked when the VM is destroyed for good, after vCPUs are gone, freeing both the individual MMUs and the global array that points to them. Because the affected code is the arm64 NV shadow-MMU layer, exposure is confined to arm64 hosts that have the nested-virtualization support compiled in and in use; the trigger mechanics beyond the VM destruction/flush path are not described in the available sources.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Local KVM access only (AV:L), privileged guest-lifecycle operations needed (PR:L), difficult-to-win teardown lifetime window (AC:H); a kernel use-after-free plausibly yields full C/I/A impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction
We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which is a Bad Idea(tm). Freeing the page tables is fair game (this is what this callback is for), but freeing the container that could still be referenced by another part of the system is not great.
Instead, grow separate destructors that gets called when we tear the VM down for good. From there, we can nuke both the individual MMUs as well as the global array that points to them, safe in the knowledge that the vcpus themselves have been destroyed already.
Executive ViewAI
A high-severity flaw in the Linux kernel's arm64 nested virtualization support could allow a local attacker with KVM privileges to corrupt host kernel memory, potentially leading to crashes or code execution. This affects only arm64 hosts running KVM with nested virtualization enabled, a non-default and recently introduced feature, so the organizational risk is limited to those specific environments.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-103680
GHSA-f55r-7vvq-j4jq
NVD
CVE.org
EPSS
VulDB
Exploit-DB