An ARM64 KVM escape sat in shipping kernels for 348 days, but only nested hosts are exposed

348 days in shipping kernels, and two stable lines died first

The behaviour behind CVE-2026-89775 reached a released Linux kernel on 28 September 2025, the day 6.17 shipped. The fix reached users in stable kernels on 11 September 2026, in 6.18.51 and 7.2.5. That is 348 days. Inside that window two stable lines took their final release without the patch: 6.17.y ended at 6.17.13 on 18 December 2025, and 7.0.y ended at 7.0.14 on 27 June 2026. The upstream fix was not written until 6 August 2026, so neither line could ever have carried it. A host tracking either of those lines cannot get this fix from kernel.org at all. It has to come from a distribution backport, or from moving the host to a line that is still alive.

That is the uncomfortable half of the story. The comfortable half is that almost nobody is in the attack path. The flaw lives in KVM's nested virtualisation code for ARM64, and nested virtualisation on ARM64 is not on unless somebody turned it on at boot. The kernel's own parameter documentation describes the nested value of kvm-arm.mode as a mode that "requires at least ARMv8.4 hardware (with FEAT_NV2)" and adds that it is experimental and "should be used with extreme caution". A plain ARM64 KVM host that never set that parameter is outside the path the researcher reported.

What the flaw does, in two sentences

When a guest running as a nested hypervisor arranges its memory in a particular way, a size calculation inside KVM comes out as zero, and the step that should drop a stale mapping when the host reclaims a page is skipped. The result is that a page of host memory that has been freed, and may already have been handed to something else, stays mapped and writable from the guest side, so the guest can read and write memory the host is using.

Hyunwoo Kim, who reported the flaw, put it this way in his disclosure post: "a freed host page stays mapped writable at a fixed address in the host kernel". He says a guest can use that to escape to the host. He also describes a second route on hosts where any local user can open /dev/kvm: such a user can create a guest and use the same defect to reach root. That second route still needs the host to have nested mode enabled.

This briefing deliberately stops at that level. The mechanism matters for deciding whether a host is in scope; the steps from a stale mapping to code execution do not, and are not reproduced here.

The record on cause, credit and reach, from the kernel CNA entry, the upstream commit and the kvmarm review thread

Question	What the record establishes	What it does not establish
Which code	One file, arch/arm64/kvm/nested.c, in KVM's nested virtualisation path	Any effect on x86 KVM, on nVHE hosts, or on protected mode (pKVM) hosts
Who found it	Reported-by Hyunwoo Kim on the upstream fix; the fix was written by Marc Zyngier and reviewed and tested by Fuad Tabba	Whether anyone else found it independently, or earlier
From which version	The kernel CNA lists the code as present from 6.16; the reviewer's note on the list says the missed invalidation "only starts at v6.17"	Whether a 6.16 host is reachable in practice; the two statements are not reconciled in the CVE record
Exploitation	The reporter states a guest to host escape and a local root path	Any observed attack, any public exploit, or any confirmed victim

Who is actually exposed

Three groups of people are reading this, and the answer is different for each.

People running their own ARM64 KVM hosts. This is the group that has to do work. Arm servers in a rack, Ampere workstations used as build hosts, continuous integration fleets, telecoms edge nodes, home and lab hypervisors. Nested mode is not the default, so most of these hosts are not in the path, but you cannot know which ones are without reading the boot line on each. Anyone who once added kvm-arm.mode=nested to test a nested setup, and never took it out, is carrying a live precondition in a comment-free boot parameter.

People running a private cloud or a hosting business on ARM64. For this group nested virtualisation is not a curiosity; it is the feature that lets a tenant run their own hypervisor. If you sell that, the precondition is deliberately on, the guest is by definition untrusted, and this is a patch-now item rather than a survey item.

Managed cloud customers on ARM instances. On the three largest providers the documented tenant path is not there to take. AWS lists nested virtualisation for Intel families only, naming M7i, M8i, C7i, C8i, R7i, R8i, X8i, I7i and their variants. Google Cloud's restrictions exclude "VMs powered by ARM processors". Microsoft's size pages for its Arm virtual machines, including the Cobalt 100 series and the older Ampere Altra series, record Nested Virtualization as Not supported. If you are a tenant on those instance families, you cannot enable the precondition inside your own virtual machine, so the reported guest to host path is not available to you.

Provider documentation on nested virtualisation for Arm instances, read on 22 September 2026

Provider	What the documentation states	What it does not cover
AWS EC2	Nested virtualisation is supported on a named list of Intel instance families; no Graviton family appears on it	What kernels AWS runs on its own Arm hosts, and what bare metal Arm customers do with them
Google Cloud	Restrictions exclude E2, memory optimised and "VMs powered by ARM processors"	Google's own host configuration, which is not a tenant-visible setting
Microsoft Azure	Arm size series, Cobalt 100 and Ampere Altra alike, list Nested Virtualization as Not supported	Azure host kernels, and any Arm size not yet documented
Oracle Cloud	No Oracle Linux page exists for this CVE and Oracle's own nested virtualisation post could not be retrieved for this briefing	Oracle's position on Ampere shapes, which this briefing does not claim to have verified

Off by default is a setting, not a control

Three comforting phrases are doing a lot of work in the coverage of this flaw: nested virtualisation is off by default, it is experimental, and it is not supported on ARM. All three are true, and none of them is a control.

"Off by default" describes the state of a host nobody has touched. A boot parameter set eighteen months ago by an engineer who has since left is still on, and nothing in the platform will tell you so unless you look. "Experimental" is a support posture, not a gate: the code compiles into the same kernel binary your distribution ships and the parameter turns it on without a special build. "Not supported" is the most misleading of the three. Red Hat's own RHEL 10 documentation says plainly that for nested virtual machines the "L0 host must be an Intel, AMD, or IBM Z system" and that nested virtualisation "currently does not work on other architectures, such as ARM". Red Hat still lists the RHEL 10 kernel and kernel-rt as Affected by this CVE, because the affected code ships in the package regardless of whether the feature is supported on that architecture.

The control, on your own estate, is a fact about each host: does its boot line contain kvm-arm.mode=nested, and is its kernel in the affected range. That is a two-line query against a configuration management database you probably already have. The comforting phrases belong in the report after that query, not instead of it.

Five records, three numbers, one flaw

The scores disagree, and the disagreement is more useful than any single figure. Everyone agrees the attack vector is local and the impact on confidentiality, integrity and availability is high. What they disagree about is whether an attacker needs privileges to reach it, and how hard it is.

CVSS v3.1 base scores by assigner, from each organisation's own record on 22 September 2026

Who scored it	Base score and vector	Their own label
Linux kernel CNA, the record's assigner	9.3 with AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H	Critical
Red Hat Product Security	8.8 with AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, marked draft	Important, with no workaround that meets its criteria
Amazon Linux Security Center	7.8 with AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H	Important
Canonical	Shows 9.3, the kernel CNA figure	Priority medium
SUSE	Shows 9.3 under both the NVD and Linux Kernel CNA columns	Critical, and every listed SUSE product is Not affected

Read the vectors rather than the numbers. The kernel CNA scored it with no privileges required, which fits a tenant who already controls a guest. Red Hat and Amazon added a privileges-required component, which fits a local user on the host. Amazon alone raised attack complexity to high. NVD itself had not added its own score when this was written: the record was still marked Received, and the only score attached to it comes from the kernel CNA. Canonical's medium priority, sitting next to a 9.3 it displays but did not assign, is the clearest sign that the number and the exposure are separate questions.

How to check a host in under a minute

Four facts decide whether a host is in the reported path: the architecture, the kernel version, the boot line and the mode KVM actually came up in. All four are readable without installing anything.

# 1. Is this an ARM64 host at all, and what kernel is it on?
uname -m -r

# 2. Was nested mode asked for on the boot line?
grep -o 'kvm-arm.mode=[a-z]*' /proc/cmdline || echo 'no kvm-arm.mode parameter'

# 3. What mode did KVM report at boot? In current kernels the
#    message carries a +NV2 suffix when nested support is active.
dmesg | grep -i 'mode initialized'

# 4. Who can create a guest on this host?
ls -l /dev/kvm

On the version check, the ranges that matter are these. Affected: 6.17 up to but not including 6.18.51, and the 7.x line up to but not including 7.2.5. Fixed upstream: 6.18.51, 7.2.5 and 7.3-rc1. Distribution kernels carry their own version numbers, so on a distribution kernel the vendor tracker is the authority rather than the upstream number.

The boot message check is an inference worth stating as one. The relevant line in current mainline prints the KVM mode and appends a marker for nested support, so a host that came up with nested virtualisation active says so in the log. Older kernels have printed that line in different forms, so treat an absent marker as a prompt to check /proc/cmdline rather than as proof.

The patch path, and where it does not exist yet

Upstream, the sequence was quick once the report landed. A first patch was posted to the kvmarm list on 27 July 2026, reviewed and tested there, and a reworked fix from the maintainer was merged 10 days later on 6 August 2026. The stable backports were tagged on 11 September 2026, five days before the public disclosure on 16 September. Distributions have been slower, and six days after disclosure most of them have nothing released.

Fix status by kernel and distribution, from each vendor's own tracker on 22 September 2026

Kernel or distribution	Fixed on the record	Not stated or still open
Mainline and stable	6.18.51, 7.2.5 and 7.3-rc1	Nothing for 6.17.y or 7.0.y, which ended at 6.17.13 and 7.0.14 before the fix existed; nothing for 7.1.y, which ended at 7.1.13
Red Hat Enterprise Linux	Versions 6 to 9 recorded as Not affected	RHEL 10 kernel and kernel-rt recorded as Affected, with no fixed version and no workaround that meets Red Hat's criteria
Ubuntu	Nothing released; priority set to medium	26.04 kernels, including the AWS, Azure and GCP builds, and the 24.04 hardware enablement 6.17 and 7.0 kernels, all recorded as needed
Debian	sid has 7.2.6-1; bookworm and trixie are marked vulnerable code not present	forky is still on 7.1.13-1 and marked vulnerable, on an upstream line that has ended
Amazon Linux	All other Amazon Linux kernels recorded as Not affected	The AL2023 kernel6.18 package is recorded as Pending Fix
SUSE	Every listed SUSE product and package is recorded as Not affected	openSUSE Tumbleweed does not appear in the product list

Two entries in that table deserve a second look. Debian forky, the release in preparation, carries a kernel from an upstream line that finished before this fix was written; it will need a rebase rather than a point update, which is ordinary work but not instant. And Ubuntu's 24.04 hardware enablement kernels on 6.17 and 7.0 sit on the same dead upstream lines, which is why those packages are marked needed rather than released: Canonical has to carry the patch itself.

The question that exposes the gap

Everything reassuring about CVE-2026-89775 is a statement about configuration. Nested virtualisation is off unless somebody switched it on. The big clouds do not offer it on Arm. Red Hat says it does not work on ARM at all. Each of those is true, and each of them is a claim about a default that some engineer, at some point, was free to change without telling anyone.

So the question to put to the infrastructure team is not whether you are affected. It is this: which ARM64 hosts boot with kvm-arm.mode=nested today, when was each of those decisions last reviewed, and can you answer from a record rather than by logging in and looking? If the answer takes a day to assemble, the defect is not the one in the kernel.