A guest-to-host escape in the Linux kernel’s KVM/arm64 code, tracked as CVE-2026-89775, lets a malicious virtual machine obtain 64-bit reads and writes to a freed page of host kernel memory, with no trap or VM exit involved. The bug was disclosed on the oss-security list on September 16 and has since drawn wider coverage as distribution advisories land. It only applies when nested virtualization is enabled, which limits exposure, but the affected population is exactly the one where a VM boundary matters most: ARM64 cloud and multi-tenant hosts that let untrusted users run their own VMs.

What’s broken

The root cause is a type truncation in the KVM/arm64 stage-1 page-table walk. When KVM emulates nested virtualization for a guest hypervisor, it walks the guest’s stage-1 tables and computes the size of the mapped region from the walk level. Due to the truncation, that size computation returns 0, which the code uses as the sentinel for “size unknown.”

The VNCR pseudo-TLB invalidation path does not treat 0 as a sentinel. It accepts it as a legitimate size, so the invalidation range collapses into an empty interval and the invalidation is always skipped. The consequence is a stale mapping: a host page that has been freed remains mapped writable at a fixed address in the host kernel’s view for the guest. The attacking guest can read and write that page directly, at native speed, and nothing on the host side traps.

Once the freed page is reallocated to something interesting on the host (page tables, slab objects, credentials), the guest holds a controlled read/write primitive into host kernel memory. That is a classic stale-mapping-to-arbitrary-write path, and the fixed address makes it more reliable than a typical race-dependent escape.

Who is affected

Exposure requires all of the following:

  • An ARM64 host running KVM.
  • Hardware with Armv8.4 and the FEAT_NV2 nested-virtualization feature.
  • Nested virtualization explicitly enabled. On arm64 this is an experimental boot-time mode and is off by default.
  • An attacker with control of a guest VM (or a guest hypervisor inside one).

Default-configured hosts are not vulnerable. Operators of ARM64 clouds, CI runners, or dev platforms that turned on nested virt so tenants can run their own hypervisors, Kata/Firecracker-style workloads inside VMs, or Android emulation stacks are the ones to check.

Fixed versions

The fix is upstream in:

  • Linux 6.18.51
  • Linux 7.2.5
  • Linux 7.3-rc1

Red Hat has published a tracker for the CVE; other distributions are backporting to their supported kernels. Check your vendor’s advisory for the exact package version, since stable-branch numbers do not map directly onto distro kernels.

Mitigation

  1. Inventory. Find ARM64 KVM hosts and determine whether nested virtualization is enabled. Look for the kvm-arm.mode=nested boot parameter, or check for FEAT_NV2 use in your hypervisor configuration.
  2. Disable nested virtualization on hosts that do not need it. Because it is off by default, removing the boot parameter and rebooting fully removes the attack surface until you can patch.
  3. Patch. Move to a fixed upstream kernel or your distribution’s backport, and reboot. Live-patching is unlikely to be practical for a bug in KVM’s nested MMU emulation, so plan for a host restart and drain VMs accordingly.
  4. Treat untrusted tenants as the priority. If you cannot patch immediately, restrict nested-virt-enabled hosts to trusted workloads only.

Detection

There is no known in-the-wild exploitation as of this writing, and the primitive produces no VM exits, so host-side telemetry from the hypervisor will not show the stale-mapping accesses themselves. Focus detection on the post-exploitation side: unexpected host kernel oopses or panics from freed-page corruption, new processes or credentials changes on the host that trace back to a VM’s qemu/crosvm process, and guest workloads that unexpectedly exercise nested-virt features (VNCR-related registers, guest-level hypervisor setup).

Why it matters

Hardware-virtualization boundaries are the last line of defense in multi-tenant cloud. Recent kernel research has focused on the container boundary (see our coverage of the AF_UNIX container escape), but VM escape bugs have far greater blast radius: one compromised guest becomes a compromised host, and every co-resident tenant with it. The default-off status of arm64 nested virtualization is what keeps this from being a fleet-wide emergency. It is also a reminder that “experimental, off by default” flags tend to get enabled in production by teams who need the feature, and those hosts need to be tracked.

References