Zapscape, la terza fuga KVM di Hyunwoo Kim mette in discussione…

CVE-2026-64561 è una vulnerabilità use-after-free nel shadow MMU di KVM/x86 scoperta da Hyunwoo Kim. Permette a un guest L1 con privilegi kernel di eseguire codice

Il 6 agosto 2026 Hyunwoo Kim ha reso pubblica CVE-2026-64561, una vulnerabilità use-after-free nel shadow MMU di KVM/x86 che consente a codice con privilegi kernel in un guest L1 di evadere l'isolamento ed eseguire istruzioni sul host Linux. È la terza escape della "trilogia" del ricercatore in appena due mesi, dopo ITScape e Januscape, tutte radicate nella medesima area del kernel. La novità non è solo il singolo bug: è l'emergere di una classe sistematica di vulnerabilità in un componente considerato tra i più critici per la sicurezza dei servizi cloud.

Punti chiave

CVE-2026-64561 è una use-after-free nel shadow MMU di KVM/x86, scoperta da Hyunwoo Kim: un guest L1 con privilegi kernel può eseguire codice sul host.
Il bug esiste dal 2020 (Linux 5.9, commit f95eec9bed76) ed è stato corretto il 21 luglio 2026 con commit 2abd5287f083; le versioni fixate sono 6.6.148, 6.12.101, 6.18.42, 7.1.6 e 7.2-rc5.
Su Intel richiede entrambi gli EPT page-walk length 4 e 5 esposti al L1; su AMD non ci sono condizioni equivalenti e la superficie d'attacco è più ampia.
Red Hat assegna CVSS 3.1 7.0 (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) e classifica CWE-825; RHEL 8, 9 e 10 sono affetti, RHEL 6 e 7 no.

Come funziona la race condition nel shadow MMU

Il meccanismo attacca la gestione delle shadow pages di KVM, il sistema di traduzione indirizzi che emula l'MMU per i guest virtualizzati. Quando un guest L1 genera un page fault, il kernel host attraversa un percorso di gestione che include il reclaim delle MMU pages per liberare spazio. Il problema, secondo la documentazione del ricercatore, è nell'ordine delle operazioni: il controllo di stale root avviene prima di make_mmu_pages_available(), ma il reclaim può invalidare quel root in una finestra di tempo non protetta.

Il fault path prosegue con un root ormai invalidato, crea child pages che ereditano role.invalid dal parent, e le inserisce nella lista delle active MMU pages. Questo viola l'invariante fondamentale che pagine marcate invalid non debbano mai risiedere su quella lista. Il risultato è un classico use-after-free: puntatori dangling su strutture già deallocate, con possibilità di scrittura post-free. Il PoC pubblicato da Kim crea un file /Zapscape owned by root sul host, dimostrando l'esecuzione di codice fuori dal contesto del guest.

"Zapscape is a stale-root check ordering flaw in KVM's shadow-MMU bookkeeping that can lead to a use-after-free"

La cronologia di una scoperta che attraversa l'intero ciclo di disclosure

Il report a security@kernel.org è datato 11 luglio 2026. La patch è stata mergeata dieci giorni dopo, il 21 luglio. È seguito un embargo coordinato con linux-distros scaduto il 1° agosto, l'assegnazione del CVE il 4 agosto e la disclosure pubblica il 6 agosto. Questa timeline mostra un processo di coordinamento funzionante, ma anche una latenza strutturale: il bug ha attraversato sei anni di kernel prima di essere identificato, e quasi un mese tra report e disclosure pubblica.

La persistenza temporale è significativa. Il range commit-to-commit copre dal 9 luglio 2020 al 21 luglio 2026. In questi sei anni, ogni sistema Linux con kernel 5.9 o superiore che esponesse nested virtualization a guest non trusted ha portato questa vulnerabilità. Le versioni corrette sono state pubblicate come 6.6.148, 6.12.101, 6.18.42, 7.1.6 e 7.2-rc5, secondo le fonti verificate.

Perché Zapscape è il terzo atto di una storia più grande

Il contesto che rende questa advisory rilevante va oltre la singola CVE. ITScape e Januscape, le due escape precedenti di Kim, condividono la medesima area di attacco: il shadow MMU di KVM/x86. Questa ricorrenza suggerisce che il problema non è un errore isolato, ma una classe di bug sistemica in un sottosistema complesso e poco auditato. Il shadow MMU gestisce stati impliciti e race condition su strutture condivise tra host e guest: è territorio naturale per use-after-free e logic flaw.

L'impatto pratico si concentra sui provider cloud multi-tenant che offrono nested virtualization. In questi ambienti, un tenant con privilegi kernel in una VM L1 può teoricamente compromettere l'hypervisor host, rompendo l'isolamento fondamentale su cui si basa l'intero modello di sicurezza del cloud pubblico. Kim ha dichiarato esplicitamente di non avere evidenza di sfruttamento in-the-wild, ma la presenza del PoC pubblico riduce la barriera per attacchi mirati.

Va notata una condizione di scope specifica per Intel: la vulnerabilità richiede che entrambi gli EPT page-walk length 4 e 5 siano esposti al L1. Su AMD, secondo le fonti, questa limitazione non esiste. Questo asimmetria architetturale significa che ambienti AMD con nested SVM/NPT presentano una superficie d'attacco più ampia, senza requisiti configurativi aggiuntivi.

Cosa fare adesso

Per gli amministratori di infrastrutture che utilizzano KVM con nested virtualization, la priorità è la verifica della versione kernel in esecuzione sui nodi host. I kernel precedenti alle versioni fixate 6.6.148, 6.12.101, 6.18.42, 7.1.6 e 7.2-rc5 sono vulnerabili e richiedono patching.

Per i provider cloud multi-tenant, la valutazione deve concentrarsi sulla necessità effettiva di esporre nested virtualization a tenant non trusted. Le fonti non specificano mitigazioni alternative oltre alla patch del kernel: l'assenza di workaround documentati rende l'aggiornamento l'unica contromisura verificabile.

Per gli operatori di sistemi RHEL, Red Hat conferma l'impatto su RHEL 8, 9 e 10 con CVSS 3.1 7.0, mentre RHEL 6 e 7 non contengono il codice vulnerabile. Il punteggio reflecte la complessità dell'attacco (AC:H) ma anche l'impatto completo su confidenzialità, integrità e disponibilità.

Il PoC di Kim non è uno exploit weaponizzato per ambienti cloud reali, ma codice dimostrativo che richiede adattamento. Questo non attenua la criticità: la pubblicazione del meccanismo completo accelera la possibilità di sviluppo di varianti operative.

Il problema del patching sostenibile degli hypervisor

Kim ha chiuso il suo repository con una raccomandazione diretta: stabilire un processo di patching sostenibile per gli hypervisor host. La frase, con la sua citazione esplicita, indica una consapevolezza di fondo: gli hypervisor sono spesso considerati "sicuri per design" grazie alla virtualizzazione, ma questa percezione genera complacency operativa. Il kernel host di un hypervisor non è meno sensibile di qualsiasi altro sistema critico, ma viene aggiornato con frequenza inferiore per timore di downtime e regressioni.

La "trilogia" del shadow MMU è un caso studio di come questa complacency si traduca in vulnerabilità persistenti. Se un singolo ricercatore ha identificato tre bug di escape in due mesi nella stessa area, la superficie di audit rimanente è probabilmente ampia. La domanda che i provider cloud devono porsi non è se arriverà una quarta escape, ma quando e se i loro processi di aggiornamento saranno sufficientemente rapidi per intercettarla.

Il dossier non specifica quanti provider espongano effettivamente nested virtualization a tenant non trusted, né fornisce stime sul numero di sistemi vulnerabili in produzione. Questi limiti lasciano irrisolta una parte della valutazione del rischio di massa, ma non riducono la criticità per le infrastrutture esposte.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti