Zapscape — KVM guest-to-host escape

Summary

How the exploitation chain works

Zapscape is a memory-corruption bug in KVM’s shadow MMU — the software page-table walker KVM uses when hardware two-dimensional paging (Intel EPT / AMD NPT) is not in play for a mapping, most notably for nested guests. The flaw is one of ordering: both x86 shadow-MMU page-fault handlers checked whether a fault had gone stale before making shadow pages available, when the check has to come after.

When a page fault is taken, direct_page_fault() (and its paging-mode twin FNAME(page_fault)) take mmu_lock and then, in the vulnerable order, first call is_page_fault_stale() — bailing with RET_PF_RETRY if the vCPU’s root has become invalid or obsolete since the fault was recorded — and only then call make_mmu_pages_available(), which reclaims shadow pages when the MMU is at its cap. The problem is that reclamation (kvm_mmu_zap_oldest_mmu_pages()) can zap the vCPU’s own, in-use root, marking it invalid. Because the stale check already ran and passed, the handler proceeds to map memory into a root that is now invalid.

Populating an invalid root would be harmless on its own, but child shadow pages inherit their parent’s role — including role.invalid. Any children created during the map/fetch are therefore created as invalid pages and linked onto the list of active MMU pages, violating the invariant (established by f95eec9bed76 in Linux 5.9) that invalid shadow pages are never on the active list. That corrupts KVM’s shadow-page bookkeeping into a use-after-free the PoC drives to host code execution. The fix simply moves the stale-root check to after make_mmu_pages_available(), so a root zapped during reclamation is seen as stale and the fault retried instead of populated.

ℹ️ The vulnerable path is the shadow MMU, which on modern EPT/NPT hardware is exercised chiefly through nested virtualization. Disabling nested virt (kvm_intel.nested=0 / kvm_amd.nested=0) removes the guest-driven path for untrusted guests. Two ways in exist: a hostile guest escaping to host root, and — where /dev/kvm is world-readable/writable (the default on EL8 and later) — an unprivileged local user reaching the same code directly. Restricting /dev/kvm closes the second without touching the first. The nested-virt path also depends on the host CPU: AMD hosts (SVM/NPT) are reachable unconditionally, while Intel hosts (VMX/EPT) are reachable only where the CPU exposes 5-level EPT to guests — Ice Lake-SP and newer — so older Intel hosts are not reachable through the disclosed path. Only a patched kernel removes the flaw — disabling nested virt or restricting /dev/kvm narrows who can reach an unpatched kernel but does not fix it.

Vulnerable commit range

The reachable lifetime is therefore v5.9 (2020) through v7.1; the fix is in mainline ≥ 7.2-rc5 and the 5.15 / 6.1 / 6.6 / 6.12 / 6.18 / 7.1 stable backports. ARM64 KVM uses a different MMU and is not affected by this bug — see ITScape for that researcher’s arm64 escape.

Patch status

What decides exposure is whether the kernel carries the 2abd5287f083 backport. Because the bug dates to v5.9, every kernel below is inside the affected window and stays vulnerable until it ships the fix. /dev/kvm exposure and nested-virt defaults change who can reach the bug, not whether the kernel is fixed.

Unusually for this family, the fix reached the 6.6, 6.12, 6.18, and 7.1 stable lines first (all on 2026-08-03); 6.1 picked it up on 2026-08-19, and 5.15 on 2026-08-27. The 5.10 LTS line carries no fix yet, so the distributions still riding it are vulnerable with nothing upstream to adopt. The first group tracks the upstream kernel itself; the rest are a focused set of x86-64 distributions (other systems named in the disclosures appear only in prose). Current kernel is the latest version observed in the row’s user-facing channel; First fixed is the first release or build carrying the fix, and Fixed since the date it first held (both stay — while a row is vulnerable).

Linux kernel

The fix reached Linus as v7.2-rc5 (2026-07-26) and the stable team backported it to the 7.1, 6.18, 6.12, and 6.6 lines on 2026-08-03 (7.1.6, 6.18.42, 6.12.101, and 6.6.148), then to 6.1.y on 2026-08-19 (6.1.183), and to 5.15.y on 2026-08-27 (5.15.218). The 7.0.y line reached end of life at 7.0.14 on 2026-06-27 without the backport; a host still on it is in-window and permanently vulnerable. The 7.1.y line has since reached end of life too, at 7.1.13 (2026-09-02) — already fixed, so a host frozen there stays patched. The 5.10.y LTS line is still maintained but carries no fix yet: it predates is_page_fault_stale() and carries the stale-root check in an older shape, so a fix there needs adaptation, unlike 6.1.y and 5.15.y where the backport landed.

When verifying a tree directly, the reordered calls are in direct_page_fault() in arch/x86/kvm/mmu/mmu.c and FNAME(page_fault) in arch/x86/kvm/mmu/paging_tmpl.h; the fix moves is_page_fault_stale() to after make_mmu_pages_available().

Debian

Debian’s linux is affected in every suite (the bug predates all of them); the security tracker’s CVE-2026-64561 record drove these assessments. trixie (stable) shipped the fix as 6.12.101-1 via trixie-security under DSA-6415-1 (2026-08-06), and sid/forky carry 7.1.6-1 or newer. bookworm’s default kernel rides 6.1.y: Debian backported the upstream 6.1.183 fix into 6.1.187-1 via bookworm-security (first seen 2026-09-08), so the default is fixed too — no DSA has been issued for it. bookworm also carries a separate opt-in linux-6.12 source package, published straight to bookworm-security at 6.12.101-1~deb12u1 (2026-08-15) under DLA-4745-1, which reached the fix even earlier than the default line.

bullseye’s Debian LTS window closed on 2026-08-31 — both its 5.10.y default and its opt-in linux-6.1 package have dropped out of the Debian security tracker’s coverage and out of the archive’s actively-tracked suite set entirely. Neither will receive another Debian security update: the 5.10.y default already had no upstream fix to adopt, and the 6.1.y opt-in package’s line only gained one upstream (6.1.183) after this window had already closed. Both rows are now permanently :x: under standard Debian support; the way off is upgrading to a supported release, or, for paying customers, Freexian’s commercial Extended LTS, which covers Debian 11 through 2031 on a per-package subscription basis this tracker cannot verify. Debian keeps /dev/kvm owned root:kvm mode 0660, so the unprivileged local vector needs kvm-group membership there; the guest-escape vector is unaffected by that.

Proxmox VE

Proxmox ships its own Proxmox-built kernels (proxmox-kernel-*), so Debian’s fix status does not carry over. Proxmox cherry-picked 2abd5287f083 into both current default series ahead of the RHEL family: PVE 9’s default 7.0 kernel (7.0.14-9-pve) and PVE 8’s default 6.8 kernel (6.8.12-40-pve), both published to pve-no-subscription with changelogs dated 2026-08-05, listing CVE-2026-64561 explicitly. Proxmox does not issue numbered advisories for these; the changelogs and support-forum threads are the public record, and pve-no-subscription receives the kernels before the enterprise repository.

Proxmox’s superseded kernel series — PVE 9’s 6.17 and 6.14, and PVE 8’s opt-in 6.14 and old 6.11 — did not receive this fix: the cherry-pick went only into the two current defaults, and those older series (last built 2026-07-28, 2026-05-15, and 2025-03-16) are no longer updated. A host booted into any of them is in-window and permanently vulnerable; the fix is to boot the release’s current default kernel.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, and every ref’s linuxPackages_latest alias has now moved to linux_7_2 as well. Both tracks sit on fixed point releases everywhere, so all of these rows are fixed; they differ only in which point release they have reached. Kernel updates land on nixpkgs master first, and each channel publishes them once its Hydra jobset passes. A channel can therefore sit days behind master, and an unstable channel is not necessarily ahead of a release channel. The -small channels (nixos-unstable-small, nixos-26.05-small) are gated on a reduced jobset and pick up kernel updates fastest.

The master and release-26.05 rows are the git branches the fix lands on. They are not Hydra-gated, so they carry a kernel bump from the moment the commit lands — typically a day or more before a channel republishes it, which is what the Fixed since dates down the group show. They are development branches, not deployment targets.

Flake inputs map onto these directly. github:NixOS/nixpkgs/nixos-unstable tracks the nixos-unstable channel — the GitHub channel branches are updated to exactly the published channel pins — and a bare github:NixOS/nixpkgs with no ref follows master. A bare nixpkgs registry input resolves by default to nixpkgs-unstable, which is a separate channel aimed at Nix users on other operating systems rather than at NixOS, so it is not gated on the NixOS tests and can hold a different kernel from nixos-unstable.

Rocky Linux / RHEL family

The EL family ships /dev/kvm world-accessible by default (EL8 and later), so on those hosts any local user — not just a guest — can reach the bug; combined with the guest-escape path this is the higher-exposure case. All of RHEL 8, 9, and 10 are fixed: Red Hat shipped RHSA-2026:45115 (RHEL 8 kernel, 4.18.0-553.147.1.el8_10) with the companion RHSA-2026:45116 (kernel-rt), RHSA-2026:45192 (RHEL 9 kernel, 5.14.0-687.30.1.el9_8), and RHSA-2026:45114 (RHEL 10 kernel, 6.12.0-211.39.1.el10_2), all dated 2026-07-24 (RHEL 6/7 are Not affected, predating the v5.9 invariant). RHEL 9’s niche kernel-rt variant (no row here) remains Affected with no RHSA yet. Red Hat has also fixed several narrower EUS/TUS/E4S streams Rocky does not rebuild — RHEL 10.0 EUS (RHSA-2026:49030, 6.12.0-55.94.1.el10_0), RHEL 8.8 TUS/E4S (RHSA-2026:47869, 4.18.0-477.156.1.el8_8), RHEL 9.4 E4S (RHSA-2026:48386, 5.14.0-427.141.1.el9_4), and RHEL 9.6 EUS (RHSA-2026:49031, 5.14.0-570.131.1.el9_6). Rocky has rebuilt past all three general-stream fixes (8 and 10 on 2026-07-26, 9 on 2026-07-27), so Rocky 8, 9, and 10 are all :white_check_mark:. Upstream, the whole RHEL family, and CloudLinux are now fixed.

CloudLinux patches its own .lve kernel builds directly and is ahead of Red Hat: per its advisory, CloudLinux 9 already ships a fixed kernel-5.14.0-687.30.1.el9_8 or newer in stable, CloudLinux 7h and 8 have kernel-4.18.0-553.150.1.lve (or newer) rolling out through the testing repositories, and CloudLinux 8 LTS / 9 LTS / 10 are in preparation. The CloudLinux Ubuntu 22.04 kernel is delivered via Canonical, with a KernelCare livepatch in preparation. Oracle Linux is expected to track the RHEL fixes once they ship.

Amazon Linux

Each AL2023 kernel stream is its own row above; status is verified from the repodata updateinfo.xml (the per-CVE ALAS pages are JS-rendered and don’t fetch headlessly). ALAS2023-2026-2057 and ALAS2023-2026-2058 (both 2026-08-17, Important) fixed the kernel6.12 stream at 6.12.100-125.179 and the default kernel stream at 6.1.180-225.360 respectively, and ALAS2023-2026-2071 (2026-08-31, Important) fixed the kernel6.18 stream at 6.18.41-94.142 — all three Amazon-specific cherry-picks, since each build sits below its line’s upstream first-fixed release (6.12.101, 6.1.183, and 6.18.42). All three currently supported AL2023 kernel streams are now fixed.

AL2 (amzn2) is not tracked here: it reached end of support on 2026-06-30 — before this tracker existed — with no ALAS for this CVE. Its 5.10 and 5.15 amazon-linux-extras kernels are in-window and permanently vulnerable (the 4.14 default predates the v5.9 introduction and is not affected). The exit for an AL2 KVM host is migrating to AL2023 (or another distribution) and adopting its fix once one ships.

Detection

Is the running kernel in the affected window and missing the fix? Compare the running kernel against the Patch status table above — the Linux kernel rows for the upstream point releases, and your distribution’s row:

uname -r

Is this an x86 host? Zapscape is x86-only (Intel or AMD); arm64 hosts are not affected by this bug:

uname -m

Is KVM in use, and is nested virtualization enabled? The shadow-MMU path is reached chiefly through nested guests; Y means nested virt is on:

cat /sys/module/kvm_intel/parameters/nested

On AMD hosts check the AMD module instead:

cat /sys/module/kvm_amd/parameters/nested

On an Intel host, is the CPU new enough to be reachable? The disclosed path needs the host to expose 5-level EPT to guests (Ice Lake-SP and newer). Empty output means the CPU predates that and the disclosed path is not reachable; AMD hosts print no such line and are reachable regardless:

grep -ow ept_5level /proc/cpuinfo

Who can open /dev/kvm? World access (e.g. crw-rw-rw-, the EL8+ default) exposes the local unprivileged vector; crw-rw---- root:kvm limits it to the kvm group:

ls -l /dev/kvm

Public PoC

The upstream PoC is in V4bel/Zapscape. CloudLinux reports that the published exploit does not run against its CloudLinux-built kernels as written — in their reproduction it crashed the attacker’s own guest rather than escaping — but on an unpatched host the flaw is a host-compromise primitive. Do not run it on a system you are not authorised to test.

Mitigation

The real fix is a patched kernel (the 2abd5287f083 backport). Until one is installed, the exposure can be narrowed.

Unload KVM where virtualization is not used (removes the bug entirely)

On a host that runs no VMs, unload and blacklist the KVM modules so the vulnerable code cannot be reached at all (no reboot needed):

sudo modprobe -r kvm_intel kvm

echo -e 'install kvm /bin/false\nblacklist kvm_intel\nblacklist kvm_amd' | sudo tee /etc/modprobe.d/disable-kvm.conf

Use kvm_amd in the first command on an AMD host. This is CloudLinux’s recommended measure for non-virtualization hosts.

Disable nested virtualization (removes the guest-driven path)

On a host that does run VMs but not nested ones, turn nested virt off and reload the module (no running nested guests):

sudo modprobe -r kvm_intel

echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/99-zapscape.conf

On an AMD host use kvm_amd in both commands. This blocks the shadow-MMU path for untrusted guests but does not close the hole for a workload that legitimately needs nested virtualization.

Restrict /dev/kvm (removes the unprivileged local vector)

Where /dev/kvm is world-accessible (EL8+), restrict it to a trusted group so unprivileged local users cannot open it directly:

sudo chmod 0660 /dev/kvm

Persist it with a udev rule:

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules

This does not stop a hostile guest escaping — it only removes the local unprivileged path. None of these measures is a fix; the kernel hole remains until patched.

Risk notes

• Multi-tenant / untrusted-guest hosts: this is a guest-to-host-root primitive from inside an otherwise isolated VM — the headline risk for anyone running untrusted guests with nested virtualization enabled.
• EL8+ hosts (/dev/kvm world-accessible): any unprivileged local user can reach the bug directly, without needing a guest — self-hosted CI and shared multi-user hosts are directly in scope. RHEL/Rocky 8, 9, and 10 now all have a vendor fix.
• AMD unconditional; Intel only Ice Lake-SP and newer: demonstrated on both vendors, so there is no blanket “AMD is safe” caveat — AMD hosts are reachable whenever nested virt is on. On Intel the disclosed path needs 5-level EPT exposed to guests, so pre–Ice Lake-SP hosts are not reachable through it; treat that as a scoping aid, not a substitute for patching a host that runs untrusted guests.
• Backports are narrow (CVE-2026-64561): the fix has landed in 7.1.6, 6.18.42, 6.12.101, 6.6.148, 6.1.183 (2026-08-19), and 5.15.218 (2026-08-27), but the 5.10.y LTS line carries no fix yet. Debian has backported it into bookworm’s 6.1.y default (6.1.187-1); bullseye’s LTS window closed on 2026-08-31 with neither its 5.10.y default nor its opt-in linux-6.1 package ever picking up a fix, so both are permanently vulnerable under standard support. Amazon has cherry-picked the fix independently, below the upstream threshold, into all three currently supported AL2023 kernel streams: the default kernel (ALAS2023-2026-2058), the kernel6.12 opt-in (ALAS2023-2026-2057), and the kernel6.18 opt-in (ALAS2023-2026-2071). Check the distribution row for your kernel.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References