As reported by The Hacker News, a newly disclosed vulnerability in the Linux kernel's KVM subsystem for ARM64—tracked as CVE-2026-89775—enables a guest virtual machine to read and write freed host kernel memory, potentially breaking out of its VM sandbox entirely. The flaw resides in the nested virtualization code path and was responsibly disclosed by researcher Hyunwoo Kim on September 16, 2026, with patches now available upstream.
Vulnerability Overview
CVE-2026-89775 is a use-after-free condition triggered when a guest arranges its memory in a way that causes a size calculation to resolve to zero. When this occurs, a critical TLB (Translation Lookaside Buffer) invalidation step is skipped, leaving a page of freed host memory mapped and writable by the guest. The guest can then read and write 64 bits at a time with no hardware trap returning control to the host—an unusually clean exploitation primitive.
- CVE ID
- CVE-2026-89775
- Severity
- High (VM escape + local privilege escalation potential; CVSS not yet formally published at time of analysis)
- Affected Software
- Linux kernel ARM64 KVM with nested virtualization enabled (exploitable from v6.17+); code present but not exploitable in v6.16
- Fixed Versions
- Linux 6.18.51, 7.2.5, and 7.3-rc1
- Affected Distributions
- Red Hat Enterprise Linux 10 kernel affected (RHEL 6–9 not affected); Ubuntu and other distros shipping affected kernel versions pending their own patch schedules
- Active Exploitation
- None observed; no exploit code publicly released
- Prerequisites
- Host must have nested virtualization enabled (experimental, off by default on ARM64); requires Armv8.4 hardware with FEAT_NV2; for local privilege escalation path, /dev/kvm must be accessible to the attacking user
Why This Matters: Two Attack Paths, One Bug
What makes CVE-2026-89775 particularly noteworthy is that it opens two distinct attack surfaces from a single root cause:
1. Virtual Machine Escape (Guest-to-Host)
On any ARM64 host running KVM with nested virtualization enabled, a malicious guest VM can exploit the skipped TLB invalidation to gain read-write access to host kernel memory. This is a textbook VM escape—breaking the fundamental isolation boundary that virtualization is supposed to guarantee. In multi-tenant cloud or hosting environments, this means a compromised or malicious tenant VM could potentially access another tenant's data or compromise the hypervisor itself.
2. Local Privilege Escalation
On systems where /dev/kvm is accessible to unprivileged users—which the researcher notes includes default Red Hat Enterprise Linux 10 configurations—a local user can create a guest VM and exploit the same bug to escalate to root. This second path significantly widens the attack surface beyond multi-tenant cloud scenarios to include any ARM64 server where users have VM creation rights.
Who Is Most at Risk
Standard ARM64 KVM hosts that never enable nested virtualization are not on the reported attack path—a critical distinction that limits but does not eliminate the blast radius. The fact that nested virtualization requires specific hardware (Armv8.4 with FEAT_NV2) and is an experimental, opt-in feature means many deployments are unaffected, but those that are affected face a severe compromise scenario.
Shield53 Recommendations
Immediate Actions
- Audit for nested virtualization: Identify all ARM64 hosts where KVM nested virtualization is enabled. Check kernel boot parameters and KVM module configuration for nested virtualization flags.
- Patch affected kernels: Apply the fix available in Linux 6.18.51, 7.2.5, or 7.3-rc1. For distribution-managed kernels, monitor your vendor's security advisory channel and apply the patched kernel as soon as it ships. RHEL 10 users should watch for Red Hat's official errata.
- Restrict /dev/kvm access: If nested virtualization is not required, disable it. If it must remain enabled, ensure /dev/kvm is only accessible to root or a dedicated virtualization service account. On RHEL 10 specifically, review the default udev rules that grant broad access to /dev/kvm.
- Disable nested virtualization if unused: Since the attack requires nested virtualization to be enabled, the most effective mitigation for most deployments is simply ensuring it remains disabled unless there is a documented business need.
- Deploy detection rules: Monitor for anomalous TLB-related activity patterns from guest VMs. While specific detection signatures are not yet available, watch for unusual memory access patterns from VM processes and unexpected /dev/kvm interactions from non-service accounts.
Strategic Considerations
- Reassess tenant isolation trust models on ARM64 infrastructure—this bug demonstrates that even well-maintained hypervisor code can introduce guest-to-host escape primitives when experimental features interact with memory management edge cases.
- Inventory experimental kernel features across your ARM64 estate. Features like nested virtualization that are marked experimental should undergo formal risk assessment before production deployment, with particular attention to their interaction with core memory management subsystems.
- Plan for faster patch deployment on ARM64 infrastructure, which may lag x86 in vendor patch timelines. Establish monitoring for upstream kernel security fixes relevant to your architecture.
Broader Implications
CVE-2026-89775 underscores a growing tension in the ARM64 virtualization ecosystem. As ARM64 servers gain market share in cloud infrastructure—driven by providers like AWS Graviton, Ampere Altra, and others—the security maturity of ARM64-specific virtualization code paths comes under increasing scrutiny. Nested virtualization, while powerful for development and certain production scenarios, introduces additional complexity in memory management that creates exactly the kind of edge cases where use-after-free conditions can flourish.
The dual attack surface—VM escape for multi-tenant compromise and local privilege escalation for single-host attacks—amplifies the practical risk. Organizations that assumed nested virtualization's experimental status and default-off configuration provided sufficient risk mitigation should reconsider that assumption, particularly on distributions that ship /dev/kvm with permissive access controls.
The responsible disclosure path and absence of observed exploitation provide a window for proactive remediation, but the clean exploitation primitive described—64-bit read-write access to host memory with no trap—means that once exploit code circulates, attacks could be both reliable and difficult to detect. Patching now, before proof-of-concept code emerges, is the strongest defensive position available.