aoripus-ltd/zapscape-fixPatch live generica del kernel per il use-after-free della shadow-MMU KVM/x86 (Zapscape, CVE-2026-64561)
English | 简体中文
Hotpatch del kernel per correggere la vulnerabilità CVE-2026-64561 (Zapscape) sugli host KVM con CentOS Stream 8 / RHEL 8 (intera serie di kernel 4.18.0):
Rischio senza patch: una macchina virtuale tenant (guest) può, con le sole proprie operazioni, evadere verso l'host ed eseguire codice con privilegi di root del kernel dell'host — compromettendo l'intera macchina fisica e tutte le sue macchine virtuali.
La patch di questo progetto: derivata da un backport della correzione ufficiale upstream di Linux (2abd5287f083), resa effettiva online tramite il meccanismo di livepatch del kernel:
✅ Nessun riavvio dell'host ✅ Nessun riavvio delle macchine virtuali ✅ Nessuna disattivazione di funzionalità di virtualizzazione ✅ Completamente trasparente
Le condizioni di attivazione di Zapscape variano per piattaforma: AMD non richiede alcun requisito hardware aggiuntivo (qualsiasi CPU che supporti SVM/NPT può attivarlo); Intel richiede il supporto di EPT a 5 livelli (EPT page-walk length 5, PWL5) e che l'host lo esponga a L1, altrimenti gli alias root/child non possono essere costruiti e tale percorso di attacco non è attivabile.
| Piattaforma | Famiglia CPU | Attivabile (richiede patch) |
|---|---|---|
| Intel | Xeon Scalable 1ª generazione — Skylake-SP (4100/5100/6100/8100) | ✗ No |
| Intel | Xeon Scalable 2ª generazione — Cascade Lake (4200/5200/6200/8200) | ✗ No (incluso il 8259CL testato in questo repository) |
| Intel | Xeon Scalable 3ª generazione — Ice Lake-SP (4300/5300/6300/8300) | ✓ Sì |
| Intel | Xeon Scalable 4ª generazione — Sapphire Rapids (8400) | ✓ Sì |
| Intel | Xeon Scalable 5ª generazione — Emerald Rapids (8500) | ✓ Sì |
| Intel | Altri (Xeon E, Cooper Lake 83xxH e modelli edge) | In base ai test effettivi |
| AMD | EPYC 1ª–3ª generazione (Naples 7001 / Rome 7002 / Milan 7003) | ✓ Sì (non richiede LA57) |
| AMD | EPYC 4ª generazione (Genoa/Bergamo/Siena 9004/8004) | ✓ Sì |
Fondamento: il 5-level paging / 5-level EPT è stato implementato per la prima volta da Intel nella microarchitettura Ice Lake (Wikipedia: Intel 5-level paging; white paper Intel "5-Level Paging and 5-Level EPT", documento n. 671442); in questo repository, su un Xeon Platinum 8259CL (Cascade Lake), il bit 7 (PWL5) di IA32_VMX_EPT_VPID_CAP (MSR 0x48C) risulta = 0 e /proc/cpuinfo non presenta la57 — confermando che Cascade Lake e le generazioni precedenti non dispongono di EPT a 5 livelli. L'NPT di AMD è sempre una walk hardware a 4 livelli; Zapscape non richiede capacità a 5 livelli, pertanto tutte le generazioni AMD sono attivabili.
⚠️ La tabella per generazioni è solo indicativa, fa fede il test effettivo (cloud provider/firmware potrebbero disabilitare funzionalità). Un solo comando per confermare se il tuo host Intel necessita della patch:
# 方法一（简单）：检查 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=不支持
⚠️ "Non attivabile" ≠ "assolutamente sicuro": significa solo che il percorso di attacco Intel di Zapscape non è valido; la shadow MMU di KVM potrebbe comunque presentare altri rischi, si prega di continuare a seguire gli aggiornamenti di sicurezza ufficiali.
Se sull'host è stato installato kernel-ml da ELRepo (kernel mainline) perché altre CVE richiedevano un kernel nuovo, lo stato della correzione di Zapscape dipende dalla versione:
| Versione kernel-ml | Stato Zapscape | Azione |
|---|---|---|
| 7.1.3 / 7.1.4 | ❌ Non corretto (sorgenti verificati) | Aggiornare a 7.1.7, oppure usare il livepatch kernel-ml di questo repository (già testato) |
| 7.1.5 / 7.1.6 | ✅ Corretto (upstream 2abd5287f083 già integrato) | Nessuna azione necessaria |
| 7.1.7 | ✅ Corretto (sorgenti verificati) | Nessuna azione necessaria |
CONFIG_LIVEPATCH=y + CONFIG_KLP_BUILD=y + sottocomando klp di objtool), senza bisogno di kpatch. Questo repository utilizza il flusso nativo del kernel objtool klp diff + post-link, prendendo come corpo sostitutivo le funzioni direct_page_fault / paging64_page_fault / paging32_page_fault / ept_page_fault già corrette in 7.1.7, per generare un modulo livepatch per 7.1.3 (livepatch/kernel-ml/, vedi livepatch/kernel-ml/README.md). Testato su 7.1.3 (compilato autonomamente, coerente con i sorgenti ELRepo 7.1.x): il modulo generato da kpatch/objtool si carica correttamente, /sys/kernel/livepatch mostra tutte e 4 le funzioni sostituite (enabled=1), la transizione è completata e le macchine virtuali in esecuzione non ne risentono.Nota: la serie 7.1.x ha rimosso il vecchio formato
klp_relocdell'era kpatch, passando alle sezioni.klp.rela.*(risolte daklp_resolve_symbols); pertanto la toolchain kpatch 0.9.x usata per 4.18 non è utilizzabile su 7.1.x; la soluzione kernel-ml di questo repository si basa interamente sulla toolchain KLP nativa del kernel.
La connettività al repository ufficiale ELRepo (elrepo.org) dalla Cina continentale è scarsa (misurata circa 15 kB/s). Utilizzare invece i mirror nazionali (misurati 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 即为成功
⚠️ L'aggiornamento del kernel richiede un riavvio per avere effetto; il riavvio invalida i livepatch già caricati sul kernel 4.18 (se il nuovo kernel include la correzione, non è necessario ricaricarli). Prima del riavvio, verificare il meccanismo di ripristino della macchina virtuale (il pannello Magic Cube Cloud avvia automaticamente le VM che gestisce).