CVE-2026-64561：KVM 虚拟机逃逸漏洞 Zapscape 原理与利用链

红队安全圈
红队安全圈

红队安全圈

2026年8月8日 08:56
重庆

在小说阅读器读本章

去阅读

CVE-2026-64561，代号 Zapscape，是一个 KVM/x86 shadow MMU 的释放后使用漏洞。在开启了嵌套虚拟化的环境下，受控的 L1 客户机能把一个原本只该留在客户机内部的页错误，变成跨过隔离边界、打到宿主机内核的逃逸。研究者已经放出了完整的 PoC，能在宿主机上以 root 身份创建文件。这篇文章把它从根因到利用链拆给你看。

这个漏洞由安全研究员 Hyunwoo Kim（@v4bel）发现并报告，2026-08-04 被正式分配 CVE 编号，名称 Zapscape。它存在于 Linux 内核 KVM/x86 的 shadow MMU（影子内存管理单元）里，是一个时序校验类的状态管理缺陷：在回收影子页时会把一个正在使用的 MMU 根标记为失效，但随后的缺页处理仍然按\"根还有效\"继续执行，于是本不该出现在活跃列表里的失效子页被挂了进去，最终演变成释放后使用（UAF）和释放后写（post-free write）。

需要明确的是，它不是一个\"任意 Linux 服务器无需认证就能 RCE\"的漏洞。触发逃逸需要嵌套虚拟化、L1 客户机内核权限，并且 AMD 和 Intel 的触发条件还不一样。但它一旦命中，跨过的就是宿主机内核边界——在把嵌套虚拟化开放给不可信租户的云环境里，这意味着被跨过的可能就是物理宿主机的边界。Red Hat 给出初步 CVSS 3.1 评分 7.0（本地攻击向量、高攻击复杂度、低权限），NVD 截至发稿尚未出分。

组件Linux 内核 KVM/x86 shadow MMU

漏洞类型Use-after-free / 释放后写

安全边界KVM 客户机到宿主机隔离

CVSSRed Hat 初步 7.0（NVD 尚无）

前提条件嵌套虚拟化 + L1 内核权限

PoC已公开（AMD 全链路 / Intel 条件触发）

01 漏洞原理：先校验根，再改世界

KVM 在普通单层虚拟化里用硬件的 Intel EPT 或 AMD NPT 做地址转换；但一旦 L1 客户机再起一个 L2，单级硬件转换就不够了，于是 L0 KVM 用软件维护的影子页来表述嵌套翻译状态。Zapscape 攻击的，就是这批影子页的生命周期和记账逻辑。

在存在漏洞的缺页处理路径里，代码大致是这样排的：先拿 MMU 锁，检查当前根是否\"失效/过期\"（stale）；然后去申请影子页配额（make\_mmu\_pages\_available）；配额不够就会回收（zap）一部分影子页；最后才去 fetch，把内存映射建到根下面。问题出在第一步和第三步之间——回收操作可能在中间把一个刚校验过的根标记成失效，但第三步不再复查，继续往这个已经失效的根下面建映射。

更关键的是子页会继承父页的 role。父页已经被标失效，新生成的子页的 role.invalid 位就被原样带了下来，但分配代码没有清这个位，直接把子页挂进了 active\_mmu\_pages。这就破坏了 KVM 的一条基本不变式：失效的影子页绝不能出现在活跃列表里。研究者把这个失效子页记作 C，被复用同时又被钉死成根的影子页记作 X。

真正的\"危险开关\"在于：顶层配额回收会跳过 root\_count 不为 0 的活跃根，但递归清理嵌套映射的子页时，那条路径只检查\"父关系是否消失\"，不检查 root\_count。于是当某个影子页同时扮演子页、又被钉成根时，回收能绕过顶层保护、递归地把这个还在用的根准备回收掉——把它从活跃列表摘掉并标失效，但因为有根引用没立即释放。而当前缺页早就过了失效检查，继续在失效根下建映射，带失效 role 的子页 C 就这么混进了活跃列表，埋下了后续的悬垂链表和释放后写。

官方补丁只动了顺序：把 stale 根检查从配额回收之前，挪到回收之后。一旦回收让当前根失效，缺页就直接 RET\_PF\_RETRY 重试，而不是继续往失效根下面建映射、收养带失效位的子页。

02 影响版本与触发条件

底层缺陷从 2008 年 KVM 开始跟踪失效根时就存在，但真正能利用的不变式是在 2020 年（Linux 5.9）引入的。也就是说，受影响区间是 Linux 5.9 起、直到各稳定分支合入修复。上游记录中已修复的稳定分支包括 6.6.148、6.12.101、6.18.42、7.1.6、7.2-rc5，主线修复提交是 2abd5287f083。

平台差异值得红队记牢：AMD 没有额外约束，公开的全链路 PoC 就是基于嵌套 SVM/NPT 打出来的；Intel 上要让 L1 同时能看到 EPT 的 4 级和 5 级页表遍历能力（PWL4 与 PWL5），L1 再手工构造出那个\"同一 GFN、同一 role 既是子页又是根\"的别名，才能触发同样的根/子重叠。换句话说，它是 KVM 这个内核组件的问题，不是 QEMU 设备模拟的问题——换掉用户态 VMM 并不能绕开漏洞，关键看底层 KVM/x86 是否把嵌套虚拟化暴露给了不可信客户机。

03 利用价值判断：红队看重什么

从红队视角看，这个漏洞的\"价值密度\"很高，但\"上手门槛\"也高：

攻击复杂度高

需要嵌套虚拟化 + L1 内核权限。普通客户机里的非特权进程拿不到逃逸所需的内核态控制力；如果想从客户机提权到 L1 内核再逃逸，那就得先有一连串前置漏洞。所以它真正危险的场景，是云厂商把嵌套虚拟化直接开放给不可信租户的多租户环境。

利用链已经打通

研究者把失效后的链表状态做成了两次跨缓存复用，先拿到 KASLR 偏移，再串起内核的 log\_wait、SRCU workqueue、usermode helper 路径，最终在宿主机 rootfs 上以 uid 0 创建 /Zapscape。公开 PoC 跑在 AMD 嵌套 SVM/NPT + Linux 7.1.3 上，最终效果是宿主机多出 root 所有的文件。

还不是\"云武器化\"

研究者自己说这是\"演示代码\"而非可直接用于云的武器化利用；目前也没有在野利用的公开说法。演示里关闭了 CONFIG\_DEBUG\_LIST / CONFIG\_LIST\_HARDENED 这类链表加固——一旦开了加固，当前 PoC 的释放后链表写会被拦下、退化成 DoS 而非逃逸。这给防守方一个明确的缓解杠杆。

04 检测与自查

这个漏洞不在网络层，靠端口扫描扫不出来，得从内核版本和虚拟化配置两头查：

先核对内核版本

uname -r

5.9 <= 内核 < 已修复稳定版 → 受影响

确认是否含修复提交 2abd5287f083

排查嵌套虚拟化是否对不可信租户开放

Intel 看 /sys/module/kvm\_intel/parameters/nested，AMD 看 /sys/module/kvm\_amd/parameters/nested。如果值是 Y 且宿主机上跑着不可信客户的嵌套 VM，风险显著上升。云/托管场景尤其要复核租户能不能拿到嵌套虚拟化能力。

开启内核链表加固

开启 CONFIG\_LIST\_HARDENED / CONFIG\_DEBUG\_LIST 一类加固，能把当前 PoC 的释放后链表写挡在 DoS 阶段，至少阻止逃逸完成。这是性价比很高的一道缓解。

05 修复方案与验证

根本修复是内核侧打补丁，主线提交 2abd5287f083，把 stale 根检查挪到 make\_mmu\_pages\_available 之后，direct 缺页和 shadow 模板缺页两条路径一起改。各发行版会跟随到 6.6.148 / 6.12.101 / 6.18.42 / 7.1.6 等已修复稳定分支。临时缓解：先关掉面向不可信租户的嵌套虚拟化，并开启内核链表加固。

升级后如何确认修复生效