Zapscape Exposes a KVM Guest Escape
Linux has fixed a shadow-MMU flaw affecting kernels from 5.9, while the researcher reports a full guest-to-host root chain under a specific nested-virtualization setup.
The 60-second version
Linux fixed a KVM/x86 shadow-MMU flaw that can invalidate an active root during reclamation; a researcher separately reports a full guest-to-host root chain under a specific AMD nested setup.
Key points
- The official affected range begins with Linux 5.9, with stable fixes listed at 6.6.148, 6.12.101, 6.18.42 and 7.1.6.
- The mainline repair is commit 2abd5287f083, which moves the stale-root check after shadow-page reclamation and retries an invalidated fault.
- The attack surface involves x86 KVM shadow MMU and nested virtualization, and the researcher says guest root is required.
- Intel additionally needs both EPT page-walk lengths 4 and 5 exposed to L1 for the reported technique; AMD has no equivalent extra condition.
- The Linux 7.1.3 AMD guest-to-host root result is a researcher-reported PoC, not an independently reproduced outcome in the cited sources.
Verdict. Patch the host kernel and remove unnecessary nested virtualization from untrusted guests; do not mistake the specific PoC environment for either universal exploitability or a reason to delay remediation.
Linux has confirmed and fixed CVE-2026-64561, a memory-safety flaw in KVM/x86's shadow MMU. The official record places the affected boundary at Linux 5.9 and identifies fixed stable releases; a separate researcher disclosure named Zapscape reports a complete guest-to-host root chain in a specific AMD nested-virtualization test environment.
Confirmed scopeWhat Linux officially confirms
The official CVE record describes an ordering flaw in KVM's shadow-MMU page-fault handling. KVM could check whether a root was stale, reclaim shadow pages and invalidate that in-use root, then continue mapping memory beneath it.
Child shadow pages inherit their parent's role. Continuing beneath an invalid root could therefore create invalid children on the active MMU-page list, violating a KVM invariant and opening a host-kernel memory-safety condition.
MechanismHow an invalid root breaks isolation
Nested virtualization lets an L1 guest run an L2 guest. The L0 host must track translation structures built by L1, so x86 KVM uses software shadow pages even when hardware EPT or NPT handles ordinary guest memory.
KVM limits the number of shadow pages assigned to a virtual machine and reclaims old ones when space runs low. Before the repair, reclamation occurred after the stale-root check. If reclamation invalidated the current root, the same fault could still create descendants under a root that was no longer valid.
The bug is not that KVM lacks a stale-root check; it is that reclamation could make the root stale after that check had already passed.
ExposureThe required conditions are specific
This is not a claim that every Linux VM can escape. The path involves x86 KVM's shadow MMU and nested virtualization. The researcher states that root privilege inside the L1 guest is required for the published attack model.
| Common conditions | An affected x86 KVM host, shadow-MMU activity associated with nested virtualization, and attacker control of the L1 guest at kernel privilege. |
|---|---|
| Intel | The researcher says nested VMX/EPT must expose both EPT page-walk length 4 and length 5 to L1; either one alone is insufficient for the demonstrated alias. |
| AMD | The researcher says nested SVM/NPT has no equivalent extra requirement for dual EPT page-walk lengths. |
| Practical exploitability | Matching prerequisites establish exposure, not guaranteed exploitation; kernel configuration, memory backend, hardening and adaptation remain material. |
DemonstrationWhat the Zapscape PoC reports
The Zapscape repository says its public demonstration targets Linux 7.1.3 with AMD nested SVM/NPT, using QEMU TCG as a controlled test platform. The researcher reports turning the invalid-page state into use-after-free behavior and then a complete guest-to-host chain with a root-owned effect on the host.
The repository also states that the code is not an immediately deployable cloud exploit. A real environment would require adaptation to the provider's host kernel configuration, memory backend and virtualization stack. This article omits operational exploit instructions and focuses on defensive assessment.
RemediationPatch levels and operator action
| Linux 6.6 stable | Fixed in 6.6.148 and later releases in the 6.6 line. |
|---|---|
| Linux 6.12 stable | Fixed in 6.12.101 and later releases in the 6.12 line. |
| Linux 6.18 stable | Fixed in 6.18.42 and later releases in the 6.18 line. |
| Linux 7.1 stable | Fixed in 7.1.6 and later releases in the 7.1 line. |
| Mainline | Fixed by commit 2abd5287f083; the CVE record identifies 7.2-rc5 as containing the original fix. |
- 1. Inventory x86 KVM hosts and identify which ones expose nested virtualization to untrusted guests.
- 2. Apply the fixed kernel package for the active stable or distribution branch, then confirm that the host is actually running the updated kernel.
- 3. Disable nested virtualization for untrusted workloads when it is not operationally required; on Intel, review the EPT capabilities exposed to L1.
- 4. Monitor host kernel logs and fleet telemetry for unexplained KVM warnings, crashes or instability, while treating detection as supplementary to patching.
- 5. Restrict local access to KVM devices as defense in depth, without treating permissions as a substitute for the kernel repair.
The action is straightforward: patch affected KVM hosts first, then reduce unnecessary nested-virtualization exposure. Keep the official vulnerability boundary and the researcher's configuration-specific full-chain claim separate when assigning severity and urgency.