EUVD-2026-108893
GHSA-2374-8v6x-x95c
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessControl guest/VMM on arm64 KVM-NV host
-
DeliveryRun a vCPU in nested L2 context
-
ExploitIssue concurrent VCPU_INIT forcing nested_mmus reallocation
-
ExecutionDereference freed s2_mmu via stale pointer
-
ImpactCorrupt host memory or crash hypervisor
Vulnerability Assessment
| Exploitation Conditions | Requires an arm64 host running KVM with nested virtualization (NV) support compiled in and in use, a guest actively executing a nested (L2) context, and a concurrent VCPU_INIT that causes the nested_mmus array to grow and relocate - the running vCPU then holds a pointer to the freed structure. Limiting factors: local access only (AV:L) with guest/VMM-level privileges to drive vCPU init and nested execution (PR:L, so exploitation is authenticated per the vector); arm64-only; NV is an experimental, non-default feature; and the trigger is a precise concurrency window (AC:H) between a relocating VCPU_INIT and an in-flight L2 run, not a deterministic single call. There is no remote or unauthenticated path. |
| Impact | Signals are consistent and point to a genuine but constrained local-privilege-escalation/host-compromise risk rather than a mass-exploitation emergency. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.0) describes a locally-reachable, high-complexity, low-privilege flaw with full confidentiality/integrity/availability impact - consistent with a use-after-free in the KVM arm64 nested-virtualization (NV) shadow page-table (nested_mmus) handling. EPSS is low (0.21%, 11th percentile) and the vulnerability is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_week' (not act_now/emergency), indicating prompt patching rather than drop-everything urgency. No SSVC exploitation/automatable/technical-impact fields were supplied in the input, so that framework cannot be independently applied. The AC:H is corroborated by the description's own trigger condition - a VCPU_INIT must occur while a vCPU is actively running an L2 guest AND the array allocation must require relocation - a timing/concurrency window rather than a straightforward call. Net: a real priority for arm64 KVM/NV hosts (virtualization/cloud substrate where a malicious or compromised guest-adjacent VMM path matters), but the local vector, race-dependent trigger, and experimental/niche feature surface keep real-world risk well below what the 7.0 score alone might imply for ubiquitous Linux generally. |
| Exploit ScenarioDerived | On an arm64 host running KVM with nested virtualization enabled, a local actor controlling guest/VMM-level vCPU operations arranges for a VCPU_INIT to grow the nested_mmus array (forcing reallocation) at the moment another vCPU is actively running a nested L2 context. That running vCPU retains a pointer to the now-freed structure, and dereferencing this stale s2_mmu leads to use-after-free that can corrupt hypervisor memory, disclose data, or crash the host. No public exploit identified at time of analysis; the only references are the upstream fix commits. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Local privilege escalation and potential host compromise in the Linux kernel's arm64 KVM nested virtualization (NV) support, caused by a use-after-free of the nested_mmus shadow page-table array. Affected builds are those containing the NV nested_mmus implementation introduced by commit 4f128f8e1aaac189f83d0f828bcdb2986d8d2e51 (from Linux 6.11 onward) and running on arm64 hosts that actually enable the experimental, non-default NV feature; fixed versions are 6.12.113, 6.18.56, 7.2.9 and 7.3. An authenticated, local actor with guest/VMM-level privileges (CVSS PR:L, AV:L) must drive a VCPU_INIT that relocates the array while another vCPU is actively executing an L2 context, a narrow concurrency window (AC:H), which yields high confidentiality, integrity and availability impact (CVSS 7.0). There is no KEV listing and no confirmed working public exploit; EPSS is 0.21% (11th percentile), consistent with a constrained, hard-to-trigger local issue rather than a mass-exploitation emergency.
RemediationAI
Apply the vendor-released kernel updates that contain the fix: 6.12.113, 6.18.56, 7.2.9 or 7.3, referencing the stable commits ea242bdc29e8a8ff0e2447a64b3841114779f3af, 81e3f065a6485626f816d791dfd5e00ddd12eff5, 512c93f4461b9a3735987f48423d438a9cd49e6a and 33346f8960c7bb6a3b4e273b5cfe25c5a8be349f, and verify distribution kernel builds include the backport. Where an immediate upgrade is not possible, the practical exposure reduction is to keep arm64 nested virtualization disabled, since NV is an experimental, non-default feature and the defect is only reachable when a nested L2 context runs concurrently with a growing VCPU_INIT; the cost is loss of nested-guest capability for workloads that rely on it, and hosts already running nested guests should be upgraded rather than relying on that configuration choice. Advisory details are available via https://nvd.nist.gov/vuln/detail/CVE-2026-98927 and the linked git.kernel.org stable commits.
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 keeps shadow stage-2 translation tables (s2_mmu structures) for guests running a nested, L2 context. In the vulnerable implementation these structures were held in the nested_mmus array, which was allocated during VCPU_INIT for the whole guest and could therefore be reallocated as it grew. If a VCPU_INIT expanded the array while a vCPU was mid-run in L2, that vCPU continued using a pointer into the previously freed structure - a stale-pointer/use-after-free condition, which the sources describe explicitly but for which no CWE identifier is supplied. The upstream fix restructures the container into an array of pointers that is allocated once at VM creation (in kvm_init_nested) sized to KVM's absolute maximum, with each VCPU_INIT contributing S2_MMU_PER_VCPU to the pool so no reallocation ever occurs; the pointer array is released in kvm_arch_destroy_vm, individual s2_mmu objects are allocated in kvm_vcpu_init_nested and freed on kvm_arch_flush_shadow_all, and vcpu->arch.vncr_array teardown was made consistent across failure paths. Exploitation is confined to arm64 hosts with the NV feature compiled in and in use, requires a concurrent VCPU_INIT racing an in-flight L2 execution, and offers no remote or unauthenticated path; the precise trigger mechanics beyond that race are not elaborated 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 only (AV:L); needs guest/VMM privileges to init vCPUs and run L2 (PR:L); trigger is a reallocation-plus-active-L2 race (AC:H); UAF yields full host 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: Fix life cycle of the nested_mmus array
The nested_mmus array holds the shadow page tables that are used when a guest is running a nested context. These structures are allocated on VCPU_INIT for whole guest, which implies that they may have to be relocated as the array grows.
Should a VCPU_INIT occur whilst a vcpu is actively running an L2 and that the allocation requires relocation, that vcpu will still be running with a pointer to the previous structure, which will have been freed.
Fix this by turning the array of structures to an array of pointers, which is now allocated at VM creation, sized to the absolute maximum that KVM can handle.
In turn, each VCPU_INIT contributes S2_MMU_PER_VCPU to the pool. No reallocation is ever performed, and the life cycle of each object is much clearer:
- the nested_mmus array is allocated in kvm_init_nested(), and freed
in kvm_arch_destroy_vm()
- s2_mmu structures are allocated in kvm_vcpu_init_nested(), and freed
on kvm_arch_flush_shadow_all()
Finally, the freeing of vcpu->arch.vncr_array is made consistent rather than being done on some failure paths, but not others.
Executive ViewAI
A newly disclosed high-severity flaw in the Linux kernel's arm64 KVM nested virtualization support could allow a privileged local user to escalate privileges and potentially compromise the host. Only organizations running arm64 hosts with the experimental nested virtualization feature enabled are exposed, so the blast radius is narrow but the impact on those systems is serious.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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.
Exploit-DB