CVE-2026-89775: Reading Host Memory From an ARM64 KVM Guest
Opening
Virtualization is the boundary that cloud isolation depends on. CVE-2026-89775, disclosed on 2026-09-16, breaks that boundary on ARM64: a guest can read and write kernel memory belonging to its host, at 64-bit granularity, without triggering a trap that would return control.
The mitigating factor is a configuration that most hosts do not have. Nested virtualization is off by default on ARM64, so the exploit path is closed unless someone deliberately enabled it.
Technical context
KVM implements virtualization for Linux in the kernel. On ARM64 it maintains a virtual CPU for each guest, and that virtual CPU has a software TLB that maps guest memory to host memory. When memory mappings change, KVM must invalidate the corresponding entries so that a guest cannot keep using a translation for memory the host has freed, moved or reassigned.
The defect is a type truncation in the first-stage page table walk. The size calculation that KVM performs to derive the range to invalidate can return zero, and zero has a defined meaning in that code path: the size is unknown. The invalidation logic for the VNCR pseudo-TLB reads that zero as a valid range size, which produces an empty range, and the invalidation is skipped entirely.
The consequence is that a freed host page stays writable and mapped at a fixed kernel address. A guest arranged to hold that translation can read and write the page at 64-bit granularity, and the hardware trap that would normally return control to the host never fires.
The affected configuration is KVM on ARM64 with nested virtualization enabled. That feature needs Armv8.4 hardware with FEAT_NV2 and is an experimental boot mode. The code was introduced by commit 7270cc9157f47, merged in 2025, and the fix was submitted as commit 8053393680d4 on 2026-08-06. The maintainers who reviewed the fix placed the point at which the skipped invalidation became reachable at v6.17, so kernels that contain the earlier commit without that follow-up change do not have the trigger.
Explanation or walkthrough
The important property of this bug is that it is silent. The guest does not need to provoke a VM exit, does not need a hypercall and does not produce the kind of event that monitoring usually watches for. It operates on memory that the host has released, from inside a context the host believes is contained. The 64-bit read and write primitive is enough to locate and modify kernel structures, which is how a memory bug becomes a guest-to-host escape.
Two exploitation paths follow from one flaw. A guest that can be created by an untrusted party reaches the host directly. Separately, if /dev/kvm is writable by unprivileged local users, an ordinary user on the host can build a malicious guest and use the same flaw to obtain root. Red Hat Enterprise Linux is named in the report as a distribution that opens the device broadly by default, and Red Hat confirmed the RHEL 10 kernel is affected while versions 6 through 9 are not.
Distribution status matters more than the upstream fix here, and it varies. Mainline Linux carries the fix in 6.18.51, 7.2.5 and 7.3-rc1. Ubuntu 26.04 is affected including its AWS, Azure and GCP kernel variants, while the 24.04 LTS generic kernel is not, though its newer hardware-enablement kernels at 6.17 and 7.0 are. Amazon Linux 2023 has a pending kernel 6.18 package while other Amazon Linux kernels are unaffected. Debian bookworm and trixie do not contain the code, sid is fixed at 7.2.6-1 and forky is affected.
The cloud picture is more reassuring than the distribution list suggests. AWS supports nested virtualization only on Intel-based instances, and Google Cloud's ARM virtual machines do not support it at all. The exploit path therefore does not exist in the standard ARM instances those providers offer. That is an accurate statement about those platforms and not a statement that no ARM64 KVM deployment anywhere carries the configuration.
Vendor severity scores span 7.8 to 9.3, and the spread reflects differing views of exploitation difficulty rather than disagreement about impact. Ubuntu, at the high end, still assigns a medium remediation priority. As of 2026-09-22 the vulnerability was not in CISA's Known Exploited Vulnerabilities catalog, there was no public proof-of-concept code, and no evidence of exploitation in the wild. Reported exploitation probability was under one percent.
Hyunwoo Kim reported the flaw, and it is his fourth KVM guest-to-host escape of 2026. Two were in x86 KVM, disclosed in July and August, and the closest in mechanism was an ARM64 escape published in June.
Defensive implications
Patch the kernel, and track it through the distribution advisory rather than the upstream commit, because the affected packages are distribution and cloud-provider kernels.
Disable nested virtualization where it is not required. The report notes that many environments have it enabled without any workload consuming it, and turning it off removes the entire attack path. Where it is required, treat the host as higher risk until the kernel package is updated.
Review the permissions on /dev/kvm. Broad local access to the device turns a local user into someone who can build a malicious guest, and it is the difference between needing a hostile tenant and needing any user account.
Accept that Red Hat published no mitigation meeting its own criteria for hosts that cannot be patched, so the choice there is between the kernel update and disabling nested virtualization.
Reachability from the internet is not the relevant metric for this class. It cannot be triggered over the network, which is also why an external scan will never tell you whether your hosts carry it. The exposure question is entirely about what runs on the host and how the device is permissioned.
References
- FreeBuf, ARM64 KVM escape analysis: https://www.freebuf.com/news/502620.html
- Tencent News, KVM high-severity vulnerability coverage: https://new.qq.com/rain/a/LNK2026092327336300/
- ZoomEye exposure measurement platform: https://www.zoomeye.org/
Top comments (0)