文章总结： CVE-2026-64561(Zapscape)是Linux内核KVM/x86shadowMMU的释放后使用漏洞，需嵌套虚拟化与L1内核权限触发。攻击者可利用时序缺陷实现客户机到宿主机的逃逸，在宿主机上以root身份创建文件。影响版本Linux5.9至修复前。建议核对内核版本、关闭不可信租户的嵌套虚拟化、开启内核链表加固以缓解风险。 综合评分： 95 文章分类： 漏洞分析,红队,渗透测试,漏洞预警,安全工具

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  检测与自查

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

1. 先核对内核版本

uname -r

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

确认是否含修复提交 2abd5287f083

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

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

3. 开启内核链表加固

     开启 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 等已修复稳定分支。临时缓解：先关掉面向不可信租户的嵌套虚拟化，并开启内核链表加固。

升级后如何确认修复生效

确认运行内核已含修复提交

git -C /usr/src/linux describe –contains 2abd5287f083

或核对发行版更新日志是否带回滚/修复版本

     在云/托管环境里，不能只看宿主机内核——要确认承载不可信租户的宿主机都升级到已修复分支，并且临时把嵌套虚拟化对不可信租户关掉，直到全量升级完成。

06  一句话总结

Zapscape 把一个 KVM shadow MMU 的”先查后改、中间被改”的时序缺陷，做成了完整客户机到宿主机的逃逸链。对红队，它是云环境嵌套虚拟化隔离的经典靶子；对运维，核对内核版本、收紧嵌套虚拟化开放面、开内核链表加固，这三步比什么都实在。

END

如果觉得有收获，欢迎点赞、在看、转发，我们下篇见。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：红队安全圈 红队安全圈 红队安全圈《CVE-2026-64561：KVM 虚拟机逃逸漏洞 Zapscape 原理与利用链》