CVE-2026-98927
High · 7.0CVSS
7.0
EPSS
0.2%
Published
Oct 23, 2026
CISA due date
—
Cloudanix analysis
A flaw in how Linux manages certain virtual machines on ARM chips could let someone break out of a virtual machine and take over the whole computer.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- High
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in KVM arm64 nested virtualization where the nested_mmus array holding shadow page tables is relocated on VCPU_INIT while an L2 guest is active, leaving a vCPU with a dangling pointer to a now-freed structure.
Why it matters to the business
A compromised guest VM could allow an attacker to corrupt hypervisor memory and potentially escape to the host, impacting all VMs and the underlying system on arm64 KVM deployments.
How an attack unfolds
An attacker with control of a guest VM enables nested virtualization, runs an L2 context, and forces a VCPU_INIT that triggers array relocation and reuse of the freed nested_mmus pointer for memory corruption or code execution in the host kernel.
How to fix it
Update the Linux kernel to a version containing the fix that allocates the nested_mmus array of pointers at VM creation time in kvm_init_nested, eliminates reallocation, and ensures consistent lifecycle handling in kvm_arch_destroy_vm and kvm_vcpu_init_nested.
How to confirm the fix worked
Confirm the patched kernel source contains the described changes to array allocation, removal of relocation logic, and consistent freeing paths for vncr_array; test that VCPU_INIT during active L2 no longer produces use-after-free conditions.
Typical attack path
- Gain code execution inside a guest VM
- Activate nested virtualization and enter an L2 context
- Trigger VCPU_INIT to force nested_mmus array relocation
- Leverage the resulting dangling pointer for host memory corruption or privilege escalation
How to detect it
Monitor kernel logs for KVM-related use-after-free or page-fault panics involving nested MMU structures; audit hypervisor logs for unexpected VCPU_INIT operations during active nested execution.
What your security team should do
- Prioritize kernel updates on arm64 systems running KVM with nested virtualization enabled
- Disable nested virtualization via KVM module parameters where the feature is not required
- Review guest VM isolation controls and limit untrusted nested VM usage
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|