aoripus-ltd/zapscape-fixGenerischer Kernel-Live-Patch für den KVM/x86-Shadow-MMU-Use-after-Free (Zapscape, CVE-2026-64561)
English | 简体中文
Ein Kernel-Hotpatch für CentOS Stream 8 / RHEL 8 (alle Kernel der 4.18.0-Reihe), der die Schwachstelle CVE-2026-64561 (Zapscape) auf KVM-Hosts behebt:
Risiko ohne Patch: Eine Tenant-VM (Guest) kann allein durch ihre eigenen Operationen aus der Isolation ausbrechen und auf dem Host mit Root-Rechten des Host-Kernels Code ausführen — und damit die gesamte physische Maschine sowie alle darauf laufenden VMs kompromittieren.
Der Patch dieses Projekts: Basierend auf dem offiziellen Upstream-Fix von Linux (2abd5287f083) als Backport erstellt, wird er über den Kernel-Livepatch-Mechanismus online wirksam:
✅ Kein Neustart des Hosts ✅ Kein Neustart der VMs ✅ Keine Deaktivierung von Virtualisierungsfunktionen ✅ Vollständig unterbrechungsfrei
Die Auslösebedingungen von Zapscape unterscheiden sich je nach Plattform: Bei AMD gibt es keine zusätzlichen Hardwareanforderungen (jede CPU mit SVM/NPT-Unterstützung kann die Schwachstelle auslösen); bei Intel muss 5-Level-EPT (EPT page-walk length 5, PWL5) unterstützt werden und der Host muss dies gegenüber L1 bereitstellen, andernfalls können die Root/Child-Aliase nicht konstruiert werden und dieser Angriffspfad ist nicht auslösbar.
| Plattform | CPU-Serie | Auslösbar (Patch erforderlich) |
|---|---|---|
| Intel | Xeon Scalable 1. Generation — Skylake-SP (4100/5100/6100/8100) | ✗ Nein |
| Intel | Xeon Scalable 2. Generation — Cascade Lake (4200/5200/6200/8200) | ✗ Nein (einschließlich des in diesem Repository getesteten 8259CL) |
| Intel | Xeon Scalable 3. Generation — Ice Lake-SP (4300/5300/6300/8300) | ✓ Ja |
| Intel | Xeon Scalable 4. Generation — Sapphire Rapids (8400) | ✓ Ja |
| Intel | Xeon Scalable 5. Generation — Emerald Rapids (8500) | ✓ Ja |
| Intel | Sonstige (Xeon E, Cooper Lake 83xxH und andere Randmodelle) | Maßgeblich sind Tests |
| AMD | EPYC 1.–3. Generation (Naples 7001 / Rome 7002 / Milan 7003) | ✓ Ja (LA57 nicht erforderlich und nicht nötig) |
| AMD | EPYC 4. Generation (Genoa/Bergamo/Siena 9004/8004) | ✓ Ja |
Grundlage: 5-Level-Paging / 5-Level-EPT wurde von Intel erstmals in der Ice-Lake-Mikroarchitektur implementiert (Wikipedia: Intel 5-level paging; Intel-Whitepaper „5-Level Paging and 5-Level EPT“, Dokumentnummer 671442); in diesem Repository wurde auf einem Xeon Platinum 8259CL (Cascade Lake) gemessen, dass Bit 7 (PWL5) von IA32_VMX_EPT_VPID_CAP (MSR 0x48C) = 0 ist und /proc/cpuinfo kein la57 enthält — was bestätigt, dass Cascade Lake und ältere Generationen kein 5-Level-EPT besitzen. AMDs NPT ist stets ein 4-stufiger Hardware-Walk, Zapscape benötigt keine 5-Level-Fähigkeit, daher ist jede AMD-Generation auslösbar.
⚠️ Die Generationstabelle dient nur als Referenz, maßgeblich sind Tests (Cloud-Anbieter/Firmware können Funktionen deaktivieren). Mit einem einzigen Befehl lässt sich feststellen, ob dein Intel-Host einen Patch benötigt:
# 方法一（简单）：检查 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=不支持
⚠️ „Nicht auslösbar“ ≠ „absolut sicher“: Es bedeutet lediglich, dass der Intel-Angriffspfad von Zapscape nicht greift; die KVM Shadow-MMU kann dennoch weitere Risiken bergen. Bitte verfolgen Sie weiterhin die offiziellen Sicherheitsupdates.
Wenn auf deinem Hostsystem kernel-ml aus ELRepo installiert wurde, weil ein anderer CVE einen neuen Kernel erforderte (Mainline-Kernel), hängt der Zapscape-Behebungsstatus von der Version ab:
| kernel-ml-Version | Zapscape-Status | Vorgehen |
|---|---|---|
| 7.1.3 / 7.1.4 | ❌ Nicht behoben (Quellcode verifiziert) | Auf 7.1.7 aktualisieren oder den kernel-ml-Livepatch aus diesem Repository verwenden (praktisch getestet) |
| 7.1.5 / 7.1.6 | ✅ Behoben (Upstream 2abd5287f083 wurde übernommen) | Keine Aktion erforderlich |
| 7.1.7 | ✅ Behoben (Quellcode verifiziert) | Keine Aktion erforderlich |
CONFIG_LIVEPATCH=y + CONFIG_KLP_BUILD=y + objtool-Unterbefehl klp),
kpatch ist nicht erforderlich. Dieses Repository verwendet den kernel-nativen objtool klp diff- + post-link-Ablauf,
mit den in 7.1.7 bereits behobenen direct_page_fault / paging64_page_fault /
paging32_page_fault / ept_page_fault als Ersatz, um ein
Livepatch-Modul für 7.1.3 zu erzeugen (livepatch/kernel-ml/, siehe
livepatch/kernel-ml/README.md).
Praktisch getestet auf 7.1.3 (selbst kompiliert, identisch mit dem ELRepo-7.1.x-Quellcode):
Das von kpatch/objtool erzeugte Modul wurde erfolgreich geladen, /sys/kernel/livepatch zeigt
alle 4 Funktionen ersetzt (enabled=1), der Übergang ist abgeschlossen, laufende virtuelle Maschinen merken nichts davon.Hinweis: 7.1.x hat das alte
klp_reloc-Format aus der kpatch-Ära entfernt und verwendet stattdessen.klp.rela.*- Abschnitte (aufgelöst durchklp_resolve_symbols); daher ist die für 4.18 verwendete kpatch-0.9.x-Toolchain auf 7.1.x nicht verwendbar; die kernel-ml-Lösung dieses Repositories basiert vollständig auf der kernel-nativen KLP-Toolchain.
Die offizielle ELRepo-Quelle (elrepo.org) hat in China eine schlechte Konnektivität (praktisch gemessen ca. 15 kB/s). Verwende stattdessen einen Inlandsspiegel (praktisch gemessen 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 即为成功
⚠️ Ein Kernel-Upgrade erfordert einen Neustart, um wirksam zu werden; ein Neustart macht bereits geladene Livepatches auf dem 4.18-Kernel ungültig (enthält der neue Kernel die Korrektur bereits, ist kein erneutes Laden nötig). Bestätigen Sie vor dem Neustart den Wiederherstellungsmechanismus der virtuellen Maschine (das Magische-Würfel-Cloud-Panel startet die von ihm verwalteten VMs automatisch wieder hoch).