CVE-2026-89775: Linux KVM on ARM64 Lets a Guest VM Escape to the Host

The KVM guest-to-host escape streak continued this week. Researcher Hyunwoo Kim, who has now found four such flaws in 2026 alone, published details of CVE-2026-89775 on September 16, a type-truncation bug in the Linux kernel's KVM/arm64 nested virtualization code that leaves freed host memory mapped and writable inside a guest VM. Fixes landed in Linux 6.18.51, 7.2.5, and 7.3-rc1.

How a zero-size calculation skips TLB invalidation

KVM on ARM64 handles nested virtualization (the ability for a guest to run its own hypervisor) through a stage-1 page-table walk that manages memory mappings between guest and host. When a guest arranges its memory in a particular way, a size calculation in that walk produces zero. That zero triggers a guard condition that skips the TLB (Translation Lookaside Buffer) invalidation step entirely. That step should clear stale address-translation entries after memory is freed.

The result is a freed page of host kernel memory that stays mapped into the guest's address space. The guest can read and write it 64 bits at a time without the hardware raising a trap. From there, a targeted write to that freed page can escalate to full host code execution: a true guest-to-host escape. The CVSS base score is 7.8, rising to 9.3 under conditions described below.

Affected hardware, distributions, and configurations

The critical caveat is hardware. ARM64 nested virtualization requires Armv8.4 silicon with the FEAT_NV2 capability and must be explicitly enabled at boot; it is off by default on ARM64. That narrows the blast radius compared with a typical kernel flaw, but narrow is not small.

On modern server infrastructure, Ampere Altra and Altra Max processors (common in AWS Graviton instances, Google Cloud Axion nodes, Azure Cobalt-based VMs, and a growing share of bare-metal ARM64 hosting) support FEAT_NV2. Distributions confirmed affected include:

• Red Hat Enterprise Linux 10
• Ubuntu 26.04 LTS, including cloud-kernel builds shipping to AWS, Azure, and GCP
• Amazon Linux AL2023: patch pending as of September 22
• Debian sid: fixed in kernel 7.2.6-1; the forky branch remained vulnerable at time of writing

There is a second exploitation path. On systems where unprivileged users can open /dev/kvm (a configuration present in some RHEL 10 installations), the same flaw enables local privilege escalation without nested virtualization being involved at all. That path raises the effective CVSS to 9.3 and means the vulnerability is not purely a cloud multi-tenancy concern.

AWS reduces its own exposure by restricting nested virtualization to Intel instances. Google Cloud currently excludes ARM VMs from the feature. Even so, any bare-metal ARM64 host, on-premises Proxmox cluster running on Ampere hardware, or self-managed KVM node with nested virtualization enabled should treat this as urgent.

Kim's four KVM escapes in nine months

CVE-2026-89775 is Hyunwoo Kim's fourth Linux KVM guest-to-host escape in nine months: ITScape (ARM64, June 2026), Januscape (x86, July 2026), Zapscape (x86, August 2026), and now this one. The cadence suggests the KVM code base has accumulated enough corner-case complexity in memory management and TLB handling that a focused researcher can keep finding new variations of the same class of flaw.

It would be a mistake to read this as evidence that KVM is uniquely dangerous. The kernel team has patched each disclosure quickly, and none of the four has been publicly exploited in the wild. But four escapes from the same subsystem by the same researcher in under a year is a signal that hypervisor isolation code deserves closer ongoing scrutiny. The operational lesson is familiar: treat hypervisor boundaries as one layer in a defense-in-depth stack, not as a final containment control.

Patching and mitigation steps

Patches are available. The fixes are in Linux 6.18.51, 7.2.5, and 7.3-rc1, and distribution-specific packages are landing in normal security channels. If you run ARM64 servers or VMs:

• Check your running kernel: uname -r, and update if below the fixed versions above.
• Verify whether nested virtualization is enabled: cat /sys/module/kvm/parameters/nested. A result of 1 means it is active.
• If you cannot patch immediately and do not need nested virtualization, disable it by adding kvm.nested=0 to your kernel command line and rebooting.
• Audit who has access to /dev/kvm on affected hosts: ls -l /dev/kvm. If unprivileged users or container runtimes have access, tighten permissions until the patch is in place.
• For Amazon Linux AL2023, watch the AL2023 security bulletin; the patch had not landed as of September 22.

There is no public proof-of-concept code and no confirmed wild exploitation as of this writing. For context, PoC research for Kim's previous KVM disclosures has typically surfaced within a few weeks of the initial report, so the patch window is finite.

Keeping hypervisor hosts patched

Four guest-to-host escapes in nine months from a single researcher is a useful forcing function. It reinforces the discipline of keeping host kernels patched on a short cycle, restricting access to hypervisor device nodes, and not treating VM boundaries as a sole containment layer. At Falcon Internet, that posture is baked into how infrastructure is managed, and disclosures like this one are the reason.