V4bel/Zapscape 来源：https://github.com/V4bel/Zapscape

KVM 逃逸三部曲

ITScape (CVE‑2026‑46316) Januscape (CVE‑2026‑53359) Zapscape (CVE‑2026‑64561)

Zapscape：KVM/x86 中的 Guest 到 Host 逃逸

摘要演示

本文档描述了由 Hyunwoo Kim（@v4bel）（https://x.com/v4bel）发现并报告的 Zapscape（CVE-2026-64561） 漏洞。这是一个 KVM 逃逸漏洞，允许 guest 在 KVM/x86 环境中逃逸到 host，并以内核（root）权限在 host 上执行命令。

Zapscape 是 KVM/x86 的影子 MMU 模拟中的一个释放后使用（use-after-free）漏洞，具体出现在影子页被回收时执行的递归 zap 路径中。仅通过 guest 侧操作即可触发该 bug，从而破坏 host 内核的影子页，并可能威胁到接受不受信任 guest 且暴露嵌套虚拟化的 KVM/x86 host 的 guest-host 隔离，尤其是多租户 x86 公有云。

有关详细的技术信息，请参阅此处。

在向 [email protected] 报告此漏洞后，约定的保密期（embargo）已结束，因此漏洞利用代码已发布到 oss-security，本 Zapscape 文档也随之公开。披露时间线请参阅技术细节文档。

PoC 结构

PoC 针对 AMD 编写，为安全测试起见，建议在 QEMU TCG 下运行。PoC 结构如下。

L0: 由 QEMU TCG 模拟的 x86_64 CPU（AMD SVM/NPT）上运行的 Linux 7.1.3 + KVM_AMD。逃逸目标
└─ L1: 由 guest poc 创建。通过 long -> PAE 切换，将同一影子页同时别名为 child 和 pinned root，随后 L1 将 UAF 升级为 L0 内核代码执行
    └─ L2: guest L1 执行 VMRUN。其内存访问触发 L0 的配额回收（quota reclaim）-> 无 root_count 保护的递归 zap -> UAF

此 PoC 并非可在云环境中直接运行的武器化漏洞利用，而是在 QEMU TCG 之上复现该漏洞及完整利用链的演示代码。要在真实云环境中使用，需要将 PoC 执行的 L1 操作移入 guest 内核模块，并根据 host 内核的 kconfig 移植漏洞利用代码。这并非难事。

PoC 使用方法

1. 下载存在漏洞的 v7.1.3 内核源码，然后基于附带的 kconfig 构建内核镜像。
2. 构建 PoC，然后使用 BusyBox 或类似工具制作合适的 initramfs，并将构建好的 PoC 放入 initramfs。

# gcc -O2 -g -static -pthread poc.c -o poc

3. 使用以下命令启动 Linux 7.1.3 目标系统。请在 QEMU v9.2.0 或更高版本上测试。

# ./qemu.sh bzImage initramfs.cpio.gz

4. QEMU TCG 启动后，运行 PoC。若利用成功，将从 guest 逃逸，并在 host 上创建由 root 拥有的 /Zapscape 文件。

/$$$$$$$$ /$$$$$$  /$$$$$$$
|_____ $$ /$$__ $$| $$__  $$
     /$$/| $$  \ $$| $$  \ $$
    /$$/ | $$$$$$$$| $$$$$$$/
   /$$/  | $$__  $$| $$____/
  /$$/   | $$  | $$| $$
 /$$$$$$$$| $$  | $$| $$
|________/|__/  |__/|__/
[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r-- 1 root root 0 Jul 29 05:27 /Zapscape
zapscape(uid=65534)$

此 PoC 旨在提供准确的信息。请勿在未经授权的系统上使用。

受影响版本

Zapscape (CVE-2026-64561) 覆盖从 f95eec9bed76（2020-07-08）（https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f95eec9bed76）到 2abd5287f083（2026-07-21）（https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2abd5287f083）的范围。

常见问题

此漏洞的影响是什么？

与 Januscape (CVE-2026-53359)（https://github.com/V4bel/Januscape）相同：

1. KVM 逃逸：仅通过 guest 侧操作，攻击者即可攻陷运行其 VM 的 host。例如，攻击者只需在公有云上租用单个实例，就能使 host 内核崩溃，从而击垮同一物理机上的所有其他租户 VM（DoS），或者以 root 权限在 host 上执行代码，进而接管 host 及其上的所有 guest（RCE）。
2. LPE：在 RHEL 等发行版上，/dev/kvm 是所有人可写（0666）的，因此非特权用户也可以将此漏洞用作 LPE 来获取 root 权限。当用作 LPE 时，host 侧的 VMM ioctl 可用，因此漏洞利用会变得更简单、更稳定。

这与 Januscape 有何关联？

它发生在同一个影子 MMU 中，但是一个根因不同的独立漏洞。话虽如此，与 Januscape 不同，在 Intel 上，只有在 EPT 页表遍历长度 4 和 5 同时暴露给 L1 时才能触发该漏洞。这是评估受影响范围时的一个重要点，必须准确理解。请参阅技术细节文档。

此漏洞会发生在 QEMU 中吗？

不会。与 Januscape 一样，它发生在内核内的 KVM 中，因此触发与否与 QEMU 的模拟无关。正因如此，它还可能威胁到自行实现并使用自家虚拟化栈的大型公有云。

我需要在 guest VM 内拥有 root 权限吗？

是的。需要 L1 内核权限。当你在公有云上获得一个实例时，通常对自己的 VM 拥有 root 权限，因此这一条件可以满足。在没有 guest root 的场景下，需要与 Dirty Frag（https://github.com/V4bel/dirtyfrag）等 LPE 漏洞链式利用。

你认为 KVM 漏洞会持续出现吗？

是的。我建议为 host 虚拟机监控程序建立可持续的补丁管理流程。凛冬将至。

三部曲之后还有续作计划吗？

希望没有。