
Generic kernel live patch for the KVM/x86 shadow-MMU use-after-free (Zapscape, CVE-2026-64561)
English | 简体中文
给 CentOS Stream 8 / RHEL 8(4.18.0 全系列内核)的 KVM 宿主机修复 CVE-2026-64561(Zapscape) 漏洞的内核热补丁:
不打补丁的风险:租户虚拟机(guest)可以仅凭自身操作逃逸到宿主机,以宿主 内核 root 权限执行代码——击穿整台物理机及其上所有虚拟机。
本项目的补丁:基于 Linux 上游官方修复(2abd5287f083)backport 而来,
通过内核 livepatch 机制在线生效:
✅ 不重启宿主机 ✅ 不重启虚拟机 ✅ 不关闭任何虚拟化特性 ✅ 全程无感
Zapscape 的触发条件分平台:AMD 无任何额外硬件要求(任意支持 SVM/NPT 的 CPU 均可触发);Intel 必须支持 5 级 EPT(EPT page-walk length 5, PWL5) 且宿主将其暴露给 L1,否则 root/child 别名无法构造,该攻击路径 不可触发。
依据:5-level paging / 5-level EPT 由 Intel 在 Ice Lake 微架构首次实现
(Wikipedia: Intel 5-level paging;Intel 白皮书《5-Level Paging and 5-Level
EPT》,文档号 671442);本仓库在 Xeon Platinum 8259CL(Cascade Lake)上实测
IA32_VMX_EPT_VPID_CAP (MSR 0x48C) 的 bit 7(PWL5)= 0,/proc/cpuinfo
无 la57——印证 Cascade Lake 及更早无 5 级 EPT。AMD 的 NPT 始终为 4 级硬件
walk,Zapscape 不需要 5 级能力,故 AMD 全代可触发。
⚠️ 代际表仅供参考,以实测为准(云厂商/固件可能禁用特性)。一条命令确认 你的 Intel 宿主机是否需要打补丁:
# 方法一(简单):检查 LA57(5-level paging)
grep -m1 flags /proc/cpuinfo | grep -o la57 && echo "有 LA57 → 需打补丁" || echo "无 LA57 → 大概率无需"
# 方法二(直接,Intel 专用):读取 EPT 能力 MSR 0x48C 的 bit 7(PWL5)
dnf install -y msr-tools && modprobe msr
V=$(rdmsr -p0 0x48c); echo "EPT PWL5 支持: $(( (0x$V >> 7) & 1 ))" # 1=支持(需打补丁) 0=不支持
⚠️ "不可触发"≠"绝对安全":仅代表 Zapscape 的 Intel 攻击路径不成立;KVM shadow MMU 仍可能有其他风险,请继续关注官方安全更新。
如果你的宿主机因其他 CVE 需要新内核而从 ELRepo 安装了 kernel-ml
(mainline 内核),Zapscape 的修复状态取决于版本:
| kernel-ml 版本 | Zapscape 状态 | 处理 |
|---|---|---|
| 7.1.3 / 7.1.4 | ❌ 未修复(源码已验证) | 升级到 7.1.7,或使用本仓库 kernel-ml livepatch(已实测) |
| 7.1.5 / 7.1.6 | ✅ 已修复(上游 2abd5287f083 已合入) | 无需任何操作 |
| 7.1.7 | ✅ 已修复(源码已验证) | 无需任何操作 |
CONFIG_LIVEPATCH=y + CONFIG_KLP_BUILD=y + objtool klp 子命令),
无需 kpatch。本仓库用内核原生的 objtool klp diff + post-link 流程,
以 7.1.7 中已修复的 direct_page_fault / paging64_page_fault /
paging32_page_fault / ept_page_fault 为替换体,生成对 7.1.3 的
livepatch 模块(livepatch/kernel-ml/,详见
livepatch/kernel-ml/README.md)。
已在 7.1.3(自编译,与 ELRepo 7.1.x 源码一致)上实测:
kpatch/objtool 生成的模块加载成功, 显示
4 个函数全部替换(enabled=1)、transition 完成,运行中的虚拟机零感知。说明:7.1.x 已移除 kpatch 时代的
klp_reloc旧格式,改用.klp.rela.*段(klp_resolve_symbols解析),因此 4.18 用的 kpatch 0.9.x 工具链在 7.1.x 上不可用;本仓库的 kernel-ml 方案完全基于内核原生 KLP 工具链。
ELRepo 官方源(elrepo.org)在国内连通性差(实测约 15 kB/s)。请改用 国内镜像(实测 4 MB/s+):
# 安装 elrepo-release(一次)
dnf install -y https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
# 把 elrepo-kernel 源切换到清华 TUNA 镜像(中科大 USTC 同样可用:
# https://mirrors.ustc.edu.cn/elrepo/kernel/el8/$basearch/)
awk '
/^\[elrepo-kernel\]/ {ink=1}
/^\[/ && !/^\[elrepo-kernel\]/ {ink=0}
ink && /^baseurl=/ { print "baseurl=https://mirrors.tuna.tsinghua.edu.cn/elrepo/kernel/el8/$basearch/"; next }
ink && /^[[:space:]]/ { next }
ink && /^mirrorlist=/ { print "#" $0; next }
{ print }
' /etc/yum.repos.d/elrepo.repo > /etc/yum.repos.d/elrepo.repo.new && \
mv /etc/yum.repos.d/elrepo.repo.new /etc/yum.repos.d/elrepo.repo
# 安装最新 mainline 内核(含 kernel-ml-devel,kpatch 构建也需要它)
dnf --enablerepo=elrepo-kernel install -y kernel-ml kernel-ml-devel
# 确认新内核成为默认启动项
grubby --default-kernel
# 输出 /boot/vmlinuz-7.1.7-1.el8.elrepo.x86_64 即为成功
⚠️ 升级内核必须重启才生效;重启会使 4.18 内核上已加载的 livepatch 失效(新内核自带修复则无需重新加载)。重启前请确认虚拟机的恢复机制 (魔方云面板会自动拉起其管理的 VM)。
内核必须支持 livepatch(
CONFIG_LIVEPATCH=y,RHEL 8 / Stream 8 默认开启), 部署第 0 步会先检查。
grep CONFIG_LIVEPATCH /boot/config-$(uname -r)
必须输出 CONFIG_LIVEPATCH=y,否则该内核无法热补丁。
# 中国大陆网络环境请用 ghproxy 加速镜像(直连 GitHub 可能失败):
# git clone https://ghproxy.net/github.com/Aoripus-LTD/Zapscape-Fix.git
git clone https://github.com/Aoripus-LTD/Zapscape-Fix.git
cd Zapscape-Fix/livepatch
dnf install -y gcc make git patch elfutils elfutils-devel \
elfutils-libelf-devel openssl-devel bc bison flex dwarves \
yum-utils dnf-plugins-core kpatch kpatch-dnf
dnf install -y kernel-devel-$(uname -r)
CentOS Stream 8 已于 2024-05-31 停止维护(EOL),默认软件源已失效,
dnf download --source kernel 在绝大多数机器上会失败。请按下面任选一种方式。
dnf 全家都能用)以阿里云镜像为例(测试环境实测可用):
# 把 Stream 8 的源从已失效的 mirrorlist 切换到 vault 快照
sed -i 's|^mirrorlist=|#mirrorlist=|; s|^#baseurl=http://mirror.centos.org|baseurl=http://mirrors.aliyun.com/centos-vault|' \
/etc/yum.repos.d/CentOS-Stream-*.repo
dnf clean all && dnf makecache
# 然后正常下载内核源码(会自动定位到正确文件)
dnf download --source kernel
清华镜像同样可用:把上面的
mirrors.aliyun.com/centos-vault换成mirrors.tuna.tsinghua.edu.cn/centos-vault。
# URL 规则:<镜像>/centos-vault/8-stream/BaseOS/Source/SPackages/Packages/kernel-<内核版本>.src.rpm
# 内核版本 = uname -r 去掉结尾的 .x86_64,例如:
curl -O http://mirrors.aliyun.com/centos-vault/8-stream/BaseOS/Source/SPackages/Packages/kernel-4.18.0-553.6.1.el8.src.rpm
# 也可以自动拼出你自己的内核版本:
VER=$(uname -r | sed 's/\.x86_64$//')
curl -O "http://mirrors.aliyun.com/centos-vault/8-stream/BaseOS/Source/SPackages/Packages/kernel-${VER}.src.rpm"
rpm2cpio kernel-*.src.rpm | cpio -idmv 'linux*.tar.xz'
tar xf linux-*.tar.xz
SRC=$(ls -d /root/linux-* | head -1)
echo "内核源码目录: $SRC"
./build-livepatch.sh -s "$SRC" -j "$(nproc)"
中国大陆网络环境请追加
-cn(kpatch 源码改走 ghproxy 镜像):./build-livepatch.sh -s "$SRC" -j "$(nproc)" -cn
脚本会自动检测内核代码形态并选择正确的补丁变体,无需手工指定。
构建成功后生成 /root/kpatch-out/zapscape_cve_2026_64561.ko。
kpatch load /root/kpatch-out/zapscape_cve_2026_64561.ko
加载过程约 2 秒,所有任务(包括运行中的虚拟机 vCPU 线程)在安全点切换, 虚拟机与业务全程无感知。
./verify-livepatch.sh
kpatch list
Loaded patch modules:
zapscape_cve_2026_64561 [enabled]
[enabled] 即补丁已生效。补丁会替换 KVM 的 4 个缺页处理函数:
direct_page_fault,1
paging64_page_fault,1
paging32_page_fault,1
ept_page_fault,1
(/sys/kernel/livepatch/zapscape_cve_2026_64561/kvm/ 下可查看,,1 表示已替换)
实测记录:2026-08-07 在真实 智简魔方 魔方云 KVM加强版(idcsmart Cloud KVM) 宿主机上、租户 VM 运行期间完成全流程验证——补丁加载 2 秒完成,VM 的 qemu 进程 PID 不变、guest uptime 连续、guest 功能完全正常,宿主机全程未重启。
kpatch disable zapscape_cve_2026_64561 # 停用补丁(任务自然回到旧代码)
kpatch unload zapscape_cve_2026_64561 # 卸载模块
回滚即时完成,内核本身从不被改写。
⚠️ 注意:宿主机重启后热补丁会失效,需要重新执行
kpatch load /root/kpatch-out/zapscape_cve_2026_64561.ko。 建议把该命令加入开机自启,或使用kpatch-dnf自动跟随内核更新。
Q:我用的内核是 4.18.0-XXX 的某个具体版本,支持吗?
支持。构建脚本会按源码形态自动选择补丁变体,覆盖 RHEL 8.0 ~ 8.10 /
CentOS Stream 8 全部 4.18.0-* 内核(变体对照表见
docs/TECHNICAL.md)。
Q:dnf download --source kernel 报错/找不到包怎么办?
这是 Stream 8 EOL 后的正常现象。按部署第 4 步把源切换到 vault 镜像
(方式 A),或直接按 URL 规则 curl 下载(方式 B)。
Q:加载补丁会影响正在运行的虚拟机吗? 不会。实测中虚拟机(qemu 进程、guest uptime、guest 内服务)全程无感。 补丁只调整 KVM 缺页处理内的两条语句顺序,不改变任何数据结构或虚拟化特性。
Q:补丁和 Red Hat 官方的关系?
本补丁是 Linux 上游官方修复(2abd5287f083)的 backport。RHEL 8 已停止
维护、没有官方 KLP,因此我们提供自建热补丁方案,机制与 Red Hat 官方 KLP
完全相同(kpatch / CONFIG_LIVEPATCH)。
Q:仓库里的 one-click.sh 一键脚本能用吗? ⚠️ 实验性,未经完整测试。一键脚本(依赖安装 → 构建 → 加载 → 验证) 逻辑与手动步骤等价,但请优先按本文档手动步骤操作;使用一键脚本前请 逐行阅读其内容。
Q:这是攻击工具吗? 不是。本仓库只包含防御性修复补丁与部署脚本。漏洞利用代码(PoC)见 漏洞作者仓库(V4bel/Zapscape), 请勿对未授权系统使用。
Zapscape-Fix/
├── README.md 本文档(中文)
├── README.en.md 英文版
├── LICENSE GPL-2.0
├── SECURITY.md 安全披露政策
├── docs/
│ ├── TECHNICAL.md 技术细节:漏洞原理、修复、变体对照表(中文)
│ └── ANALYSIS.md 逐行代码证据(英文,面向研究者)
├── patches/ 7 个内核代码形态的补丁变体
└── livepatch/
├── build-livepatch.sh 构建热补丁模块(自动选变体,支持 -cn 镜像模式)
├── load-livepatch.sh 加载补丁
├── verify-livepatch.sh 验证补丁
├── install-deps.sh 自动安装前置环境(辅助)
├── one-click.sh 一键部署(⚠️ 实验性)
└── kernel-ml/ kernel-ml 7.1.3/7.1.4 专用方案(内核原生 objtool
klp 工具链,已实测;含 build-klp.sh / load-klp.sh
/ 源码 / 文档)
VMX_EPT_PAGE_WALK_4_BIT/_5_BIT,Linux 内核头文件 arch/x86/include/asm/vmx.h)arch/x86/kvm/vmx/nested.c)感谢 林枫云(四川)网络科技有限公司(GitHub: @Edakerx) 在 PoC 泄露后第一时间为我们提供了用于验证测试的服务器。
| 平台 | CPU 系列 | 可触发(需打补丁) |
|---|
| Intel | Xeon Scalable 第 1 代 — Skylake-SP(4100/5100/6100/8100) | ✗ 否 |
| Intel | Xeon Scalable 第 2 代 — Cascade Lake(4200/5200/6200/8200) | ✗ 否(含本仓库实测的 8259CL) |
| Intel | Xeon Scalable 第 3 代 — Ice Lake-SP(4300/5300/6300/8300) | ✓ 是 |
| Intel | Xeon Scalable 第 4 代 — Sapphire Rapids(8400) | ✓ 是 |
| Intel | Xeon Scalable 第 5 代 — Emerald Rapids(8500) | ✓ 是 |
| Intel | 其他(Xeon E、Cooper Lake 83xxH 等边缘型号) | 以实测为准 |
| AMD | EPYC 第 1–3 代(Naples 7001 / Rome 7002 / Milan 7003) | ✓ 是(无 LA57 也无需) |
| AMD | EPYC 第 4 代(Genoa/Bergamo/Siena 9004/8004) | ✓ 是 |
/sys/kernel/livepatch| 项 | 要求 |
|---|
| 操作系统 | CentOS Stream 8 / RHEL 8(含 8.0 ~ 8.10 全部分支) |
| 虚拟化平台 | 智简魔方 魔方云 KVM加强版(idcsmart Cloud KVM)——已实测通过 |
| 内核 | 4.18.0-* 任意子版本(已覆盖 4.18.0-80 ~ 4.18.0-553 全部代码形态) |
| 权限 | root |
| 依赖 | gcc、make、git、patch、elfutils、openssl-devel、bc、bison、flex、dwarves、kpatch、kernel-devel(与运行内核同版本)、内核源码 RPM |
| 时间 | 首次构建约 20–40 分钟(取决于 CPU 核数) |