Zapscape CVE-2026-64561：KVM虚拟机逃逸漏洞深度分析

导语：2026年8月6日，安全研究人员Hyunwoo Kim（金贤宇）公开了一个足以让云服务商脊背发凉的Linux内核漏洞——Zapscape（CVE-2026-64561）。这个漏洞藏在KVM/x86的影子内存管理单元里，本质是一个”先检查根再改变世界”的时序错误。利用它，拥有L1虚拟机内核权限的攻击者可以逃逸出虚拟机隔离，以root身份在宿主机上执行任意代码。公开的PoC演示了在AMD嵌套SVM/NPT环境下成功逃逸，并在宿主机创建了/Zapscape文件——属主root，权限0644。云计算的多租户安全边界，正在被重新评估。

一、漏洞概述

属性	详情
CVE编号	CVE-2026-64561
公开名称	Zapscape
漏洞类型	虚拟机逃逸（Guest-to-Host Escape），Use-After-Free
CWE分类	CWE-825（过期指针解引用 / Expired Pointer Dereference）
影响组件	Linux内核 KVM/x86 影子MMU（Shadow MMU）
CVSS评分	Red Hat初步评分7.0（Local攻击向量）；NVD尚未最终定分
影响范围	Linux 5.9起直至修复版本（6.6.148、6.12.101、6.18.42、7.1.6、7.2-rc5）
发现者	Hyunwoo Kim（金贤宇，@v4bel）
发现时间	2025年7月11日私下报告，2026年8月6日公开披露
上游修复	Commit 2abd5287f083
公开PoC	是（GitHub: V4bel/Zapscape）
野外利用	暂无公开报告

这并不是金贤宇第一次发现KVM漏洞。他的作品集中还包括Januscape（CVE-2026-53359，2026年7月公开）和ITScape（CVE-2026-46316，KVM/arm64逃逸）。连续三位数的KVM漏洞被同一人挖出——这不是运气，是专注。

二、技术背景：KVM与影子MMU

2.1 虚拟化的层级结构

理解Zapscape，先要理解KVM嵌套虚拟化的三层架构：

物理 x86 硬件
     │
     ▼
┌─────────────────────┐
│  L0：Linux宿主机     │
│  KVM                 │
└─────────────────────┘
     │
     ▼
┌─────────────────────┐
│  L1：客户机/虚拟化层  │
│  （攻击者可控）        │
└─────────────────────┘
     │
     ▼
┌─────────────────────┐
│  L2：嵌套客户机       │
└─────────────────────┘

L0是运行KVM的宿主机操作系统，L1是客户机（如果是虚拟化平台本身，那就是客户机的宿主机），L2是在L1内部再运行的嵌套虚拟机。

2.2 为什么需要影子页表

KVM需要管理内存地址转换。在普通单层虚拟化下，Intel EPT（Extended Page Tables）或AMD NPT（Nested Page Tables）能在硬件层面完成大部分客户机虚拟地址到宿主机物理地址的转换。

但引入了嵌套虚拟化后问题变复杂了：L1为L2构建的EPT/NPT映射，还需要再经过L0的地址翻译——单层硬件转换已经不够用了。L0 KVM因此引入了软件生成的影子页表（Shadow Page Tables），来追踪L1为L2构建的嵌套EPT/NPT状态。

这些影子页表由struct kvm_mmu_page结构管理，每个影子页表包含：

link：链入VM的active_mmu_pages链表
role：页表层级、是否direct、访客模式、以及invalid状态
root_count：该页表被用作MMU根的次数（ quota回收时会跳过root_count非零的页）
parent_ptes：指向所有父页表的指针

2.3 漏洞影响什么样的环境

AMD平台：无特殊限制，只要启用嵌套虚拟化即可触发，公开PoC即针对AMD SVM/NPT。

Intel平台：需同时满足——L1客户机能见到EPT页表遍历长度4和5（即两层EPT结构）。这是因为Intel的别名（alias）构造路径与AMD不同，需要更深的EPT层级才能复现。

换言之，普通公有云上如果你租了一个开启了嵌套虚拟化的实例，就满足了这个前提条件。

三、漏洞根因：检查滞后导致的UAF

3.1 问题的本质

Zapscape的本质是一个时序错误：KVM在页面故障处理时，先检查了当前影子根是否过期（stale），然后才去确保有足够的影子页表配额——而这个确保配额的操作本身可能会使刚才检查过的根失效。但KVM没有再次检查，直接在新分配的子页上继续执行。

来看关键代码路径（Linux 7.1.3漏洞内核）：

// 页面故障处理入口
r = RET_PF_RETRY;
write_lock(&vcpu->kvm->mmu_lock);

// [5] 只检查根在故障开始时的状态
if (is_page_fault_stale(vcpu, fault))
    goto out_unlock;

// [6] 确保影子页配额——这里可能触发递归zap，使当前根失效！
r = make_mmu_pages_available(vcpu);
if (r)
    goto out_unlock;

// [7] 直接在同一个根上取页——没有再次检查根是否仍然有效！
r = FNAME(fetch)(vcpu, fault, &walker);

而make_mmu_pages_available()的实现在配额不足时会调用kvm_mmu_zap_oldest_mmu_pages()——这个zap操作可以递归地使当前正在使用的影子根失效。

3.2 配额回收的递归zap路径

顶层quota回收 Walker 在[8]处会跳过root_count != 0的活跃根——这意味着正在被用作MMU根的页面不会直接在顶层被回收。但递归zap路径（[9]处）——在删除父页表项时递归清理子页——没有检查root_count，只判断”最后一个父页表项是否消失”：

// 递归zap路径，没有root_count检查！
if (tdp_enabled && invalid_list &&
    child->role.guest_mode &&
    !atomic_long_read(&child->parent_ptes.val))
    return kvm_mmu_prepare_zap_page(kvm, child, invalid_list);

这就产生了一个漏洞：一个影子页X可以被同时用作嵌套页表的根（pinned root）和另一个嵌套页表的子页。一旦X在配额回收的递归zap路径中被选中，它的role.invalid会被标记为1，但其root_count仍然>0（因为还在被用作根），所以不会被立即释放。

3.3 Use-After-Free的完整链路

别名构造：L1客户机通过特定内存操作，使同一个影子页X既成为某个嵌套页表的子页，又成为另一个嵌套页表的pinned root（通过PAE别名）
stale root过站：L2的内存访问触发L0的quota reclaim → 递归zap选中了X的父页 → 父页删除时递归zap X → X从活跃列表移除（list_del(&sp->link)），但因root_count>0暂不释放 → role.invalid = 1标记为无效
无效子页混入活跃列表：在X已被标记为invalid之后，故障处理路径[7]仍然继续，在X下创建新的子页C → C继承X的invalid状态 → C被加入active_mmu_pages列表
双链表附着与UAF：后续某次操作中，同一个link指针被两次list_add，然后页面被释放，但链表中仍存在悬挂指针 → post-free write
利用post-free write：金贤宇用两段跨缓存（cross-cache）喷射配合KASLR泄露，通过log_wait→ SRCU workqueue→ usermode helper路径，最终在宿主机上以root权限创建了/Zapscape文件

四、PoC详解

4.1 获取与构建

# 克隆PoC仓库
git clone https://github.com/V4bel/Zapscape
cd Zapscape

# 下载并构建有漏洞的内核（Linux 7.1.3）
# 需要使用仓库中捆绑的kconfig配置

# 编译PoC
gcc -O2 -g -static -pthread poc.c -o poc

# 用BusyBox制作initramfs，将poc放入

# 启动QEMU（需要QEMU v9.2.0+）
./qemu.sh bzImage initramfs.cpio.gz

4.2 运行环境要求

宿主机OS：Linux 7.1.3 + KVM_AMD（AMD SVM/NPT）
CPU：AMD x86_64（PoC针对AMD编写）
模拟器：QEMU TCG（推荐用TCG而非硬件加速，避免测试时破坏宿主机）
嵌套虚拟化：需在BIOS/宿主内核中启用嵌套虚拟化（modprobe kvm-amd nested=1）

4.3 执行效果

在L1客户机中以root身份运行poc，成功利用后：

/$$$$$$$$ /$$$$$$ /$$$$$$$
|_____ $$ /$$__ $$| $$__  $$
 /$$/ | $$  $$| $$  $$
 /$$/ | $$$$$$$$| $$$$$$$/
 /$$/ | $$__ $$| $$____/
 /$$/ | $$ | $$| $$
 /$$$$$$$$| $$ | $$| $$
|________/|__/ |__/|__/

[+] /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文件存在，属主root，攻击者从虚拟机内部成功越界到了宿主机内核空间。

4.4 云环境武器化难点

金贤宇本人在GitHub上明确说明：”这不是能在云环境直接运行的武器化exploit。”

原因在于：

L1内核模块化：当前PoC的L1攻击动作是直接在L1内核中构造的，要武器化需要将这些动作封装进一个L1内核模块
内存布局适配：不同的宿主内核kconfig有不同的内存布局，需要调整喷射参数
稳定性问题：云环境中宿主机可能有其他负载，内存布局动态变化

金贤宇的结论是：”这不是一个困难的任务”（This is not a difficult task）——换言之，有能力的攻击者大约几天内就能完成云环境适配。

五、附加攻击面：本地权限提升

除了虚拟机逃逸，Zapscape还有另一个攻击场景：本地权限提升（LPE）。

在某些Linux发行版（如基于RHEL的系统）上，/dev/kvm是全局可写的（权限0664），意味着非特权用户也能访问KVM接口。一旦获得KVM访问权限，就可以利用同样的漏洞路径实现从普通用户到root的权限提升。

此时由于可以直接使用宿主机侧的VMM ioctl，exploit反而会变得更简单、更稳定——不再需要复杂的嵌套虚拟化构造。

六、影响范围与修复

6.1 受影响版本

版本	状态
Linux < 5.9	不受影响（漏洞2020年才引入）
Linux 5.9 ~ 6.6.147	受影响
Linux 6.6.148	已修复
Linux 6.12 ~ 6.12.100	受影响
Linux 6.12.101	已修复
Linux 6.18 ~ 6.18.41	受影响
Linux 6.18.42	已修复
Linux 7.1 ~ 7.1.5	受影响
Linux 7.1.6	已修复
Linux 7.2-rc5	已修复

Debian发行版中，bullseye、bookworm、trixie、forky均受影响，sid已在7.1.6-1中修复。

6.2 修复方案

上游修复（commit 2abd5287f083）的核心改动是：将stale-root检查移到make_mmu_pages_available()之后。如果配额回收使当前根失效，KVM现在会返回RET_PF_RETRY，重启页面故障处理，而非在已失效的根上继续建立映射。

管理员应：

# 检查当前内核版本
uname -r

# 更新到修复版本
sudo apt update && sudo apt upgrade linux-image-$(uname -r)
# 或对应发行版的内核更新命令

对于无法立即更新的环境，如果业务不需要嵌套虚拟化，可以在宿主内核中禁用嵌套虚拟化：

# 临时禁用（需重启生效）
echo "options kvm-amd nested=0" | sudo tee /etc/modprobe.d/kvm-amd.conf

但这是以丧失虚拟化功能为代价的，不是长久之计。

七、检测与监控建议

对于公有云/托管服务提供商，以下行为应触发告警：

单个L1客户机实例对宿主机内核造成异常压力（大量页面故障、内存分配异常）
客户机内部出现异常的MMU相关内核错误
/Zapscape等异常文件出现在宿主机文件系统

对于企业内部KVM宿主机，建议通过内核日志监控：

dmesg | grep -i "kvm.*mmu"
dmesg | grep -i "zap"

八、总结

Zapscape（CVE-2026-64561）是一个隐藏在KVM/x86影子MMU状态管理中的时序错误，攻击者巧妙地利用”先检查后改变”的race condition，将一个状态管理缺陷升级为完整的虚拟机逃逸。

这个漏洞的特殊之处在于：

攻击门槛相对低：只需要L1 guest kernel权限（租户通常就有），不需要完整的RCE或越狱
影响范围精准：仅影响启用嵌套虚拟化的KVM/x86环境，但这类环境在云服务商中极为常见
修复已到位：上游修复已合并，各发行版正在推送补丁
武器化难度中等：研究者已明确指出”不是困难任务”

对于多租户公有云来说，Zapscape是一记警钟：虚拟化隔离边界并不像想象中那么牢固。红队成员如果遇到开启了嵌套虚拟化的云上L1主机，可以把这个漏洞列入武器库备选。

文章版权归作者所有，未经允许请勿转载。

THE END

Zapscape：CVE-2026-64561 Linux内核KVM虚拟机逃逸漏洞深度分析