Zapscape-Fix — Updated!
Generic kernel live patch for the KVM/x86 shadow-MMU use-after-free (Zapscape, CVE-2026-64561)
Zapscape-Fix — CVE-2026-64561 Kernel Live Patch (KVM/x86)
English | 简体中文
A kernel live patch that fixes CVE-2026-64561 (Zapscape) on
CentOS Stream 8 / RHEL 8 KVM hosts (all 4.18.0-* kernels).
Without the patch: a tenant VM (guest) can escape to the host with guest-side actions alone and execute code with host kernel root — taking down the physical host and every VM on it.
This patch: a backport of the upstream Linux fix (2abd5287f083),
applied online via the kernel livepatch mechanism:
✅ no host reboot ✅ no VM restart ✅ no virtualization feature disabled ✅ fully transparent
Table of Contents
- Affected CPUs
- Kernel-ML (ELRepo mainline) Support
- System Requirements
- Deployment
- Verifying the Patch
- Rollback
- FAQ
- Project Layout
- References
- Copyright & License
Affected CPUs
Zapscape's trigger conditions differ by platform: AMD has no extra hardware requirement (any CPU with SVM/NPT can trigger it); Intel must support 5-level EPT (EPT page-walk length 5, PWL5) and the host must expose it to L1 — otherwise the root/child alias cannot be built and this attack path does not exist.
| platform | CPU family | triggerable (needs the patch) |
|---|---|---|
| Intel | Xeon Scalable 1st Gen — Skylake-SP (4100/5100/6100/8100) | ✗ no |
| Intel | Xeon Scalable 2nd Gen — Cascade Lake (4200/5200/6200/8200) | ✗ no (incl. the 8259CL tested for this repo) |
| Intel | Xeon Scalable 3rd Gen — Ice Lake-SP (4300/5300/6300/8300) | ✓ yes |
| Intel | Xeon Scalable 4th Gen — Sapphire Rapids (8400) | ✓ yes |
| Intel | Xeon Scalable 5th Gen — Emerald Rapids (8500) | ✓ yes |
| Intel | others (Xeon E, Cooper Lake 83xxH, edge SKUs) | verify on the actual box |
| AMD | EPYC 1st–3rd Gen (Naples 7001 / Rome 7002 / Milan 7003) | ✓ yes (no LA57 needed) |
| AMD | EPYC 4th Gen (Genoa/Bergamo/Siena 9004/8004) | ✓ yes |
Basis: 5-level paging / 5-level EPT was first implemented by Intel in
the Ice Lake microarchitecture (Wikipedia: "Intel 5-level paging"; Intel
white paper 5-Level Paging and 5-Level EPT, doc 671442). Measured on the
Xeon Platinum 8259CL (Cascade Lake) used for this repo:
IA32_VMX_EPT_VPID_CAP (MSR 0x48C) bit 7 (PWL5) = 0, and
/proc/cpuinfo has no la57 — confirming Cascade Lake and older have no
5-level EPT. AMD's NPT is always a 4-level hardware walk; Zapscape needs no
5-level capability there, so all AMD generations are affected.
⚠️ The table is a guide — measure on your actual box (vendors/firmware may disable features). One command to check whether your Intel host needs the patch:
# Method 1 (simple): check LA57 (5-level paging)
grep -m1 flags /proc/cpuinfo | grep -o la57 && echo "LA57 present -> patch needed" || echo "no LA57 -> most likely not needed"
# Method 2 (direct, Intel only): read EPT capability MSR 0x48C bit 7 (PWL5)
dnf install -y msr-tools && modprobe msr
V=$(rdmsr -p0 0x48c); echo "EPT PWL5 support: $(( (0x$V >> 7) & 1 ))" # 1=supported (patch needed) 0=not supported
⚠️ "Not triggerable" ≠ "absolutely safe": it only means the Zapscape Intel path does not exist; other KVM shadow-MMU risks remain — keep following official security updates.
Kernel-ML (ELRepo mainline) Support
If your host runs an ELRepo kernel-ml (mainline) kernel — e.g. because
other CVEs forced a kernel upgrade — Zapscape's fix state depends on the
version:
| kernel-ml version | Zapscape state | action |
|---|---|---|
| 7.1.3 / 7.1.4 | ❌ vulnerable (verified in source) | upgrade to 7.1.7, or apply this repo's patch |
| 7.1.5 / 7.1.6 | ✅ fixed (upstream 2abd5287f083 merged) | nothing to do |
| 7.1.7 | ✅ fixed (verified in source) | nothing to do |
- Recommended: upgrade kernel-ml to the current release (7.1.7) — the vulnerability is fixed upstream, no live patch needed.
- Temporary hardening for 7.1.3/7.1.4:
build-livepatch.shauto-detects the mainline code shape and pickspatches/cve-2026-64561-kernel-ml.patch(a backport exactly equivalent to upstream2abd5287f083; verified applicable on 7.1.3/7.1.4 sources and rejected on the already-fixed 7.1.7). Same zero-downtime live patching.
Installing kernel-ml in mainland China (ELRepo mirrors)
The official ELRepo repos (elrepo.org) are very slow from mainland China (measured ~15 kB/s). Use a domestic mirror instead (measured 4 MB/s+):
# install elrepo-release once
dnf install -y https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
# point elrepo-kernel at the TUNA mirror (USTC works too:
# 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
# install the latest mainline kernel (kernel-ml-devel is needed for
# kpatch builds too)
dnf --enablerepo=elrepo-kernel install -y kernel-ml kernel-ml-devel
# confirm the new kernel is the default boot entry
grubby --default-kernel
# expect /boot/vmlinuz-7.1.7-1.el8.elrepo.x86_64
⚠️ A kernel upgrade requires a reboot to take effect; the reboot invalidates any live patch loaded on the 4.18 kernel (not needed on the fixed 7.1.7). Before rebooting, make sure your VMs are recoverable (the 魔方云 panel restarts the VMs it manages).
System Requirements
| item | requirement |
|---|---|
| OS | CentOS Stream 8 / RHEL 8 (8.0 through 8.10) |
| virtualization platform | 智简魔方 魔方云 KVM加强版 (idcsmart Cloud KVM) — tested & verified |
| kernel | any 4.18.0-* (all code shapes from 4.18.0-80 to 4.18.0-553 covered) |
| privilege | root |
| dependencies | gcc, make, git, patch, elfutils, openssl-devel, bc, bison, flex, dwarves, kpatch, kernel-devel (matching uname -r), kernel source RPM |
| time | first build 20–40 min (CPU-core dependent) |
The kernel must support livepatch (
CONFIG_LIVEPATCH=y, default on RHEL 8 / Stream 8); deployment step 0 checks this first.
Deployment
Step 0 — confirm the kernel supports livepatch
grep CONFIG_LIVEPATCH /boot/config-$(uname -r)
Must print CONFIG_LIVEPATCH=y; otherwise this kernel cannot be live-patched.
Step 1 — get this project
# In mainland China, use the ghproxy mirror (direct GitHub may fail):
# 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
Step 2 — install the toolchain
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
Step 3 — install kernel-devel (must match the running kernel)
dnf install -y kernel-devel-$(uname -r)
Step 4 — fetch the kernel source ⚠️ important
CentOS Stream 8 reached EOL on 2024-05-31 — the default repos are dead,
so dnf download --source kernel fails on virtually every machine. Use
either method below.
Method A: switch dnf to a vault mirror (recommended; the whole dnf works again)
Using the Aliyun mirror (verified working in our test environment):