Il 6 luglio 2026 il ricercatore Hyunwoo Kim ha reso pubblico CVE-2026-53359, soprannominato "Januscape": un use-after-free nel codice shadow MMU di Linux KVM che permette a una macchina virtuale maliziosa di compromettere l'host fisico sia su processori Intel che AMD. Il bug è presente dal 2010, il PoC ufficiale causa il panic dell'host, e una versione non pubblica dell'exploit consentirebbe l'esecuzione di codice arbitrario completo.
- Il bug risiede nel codice shadow MMU condiviso tra Intel e AMD, il primo escape KVM x86 cross-vendor noto pubblicamente.
- L'attacco richiede root nella VM guest e nested virtualization abilitata, che forza l'uso del legacy shadow paging anche su hardware moderno.
- Il codice vulnerabile è in linea dal commit 2032a93d66fa dell'agosto 2010: circa 16 anni di presenza nel kernel.
- La fix è una sola riga in
kvm_mmu_get_child_sp(), aggiunta dal maintainer KVM Paolo Bonzini e disponibile nelle versioni kernel rilasciate il 4 luglio 2026.
Perché nested virtualization espone codice legacy mai pensato per il multi-tenant
KVM, il modulo di virtualizzazione del kernel Linux, usa normalmente estensioni hardware come Intel EPT o AMD NPT per gestire la memoria delle VM guest. Queste tecnologie moderne non attraversano il percorso vulnerabile. Ma quando la nested virtualization è attiva — una VM guest che a sua volta esegue un hypervisor — KVM deve ricorrere al vecchio shadow paging, un meccanismo software che traduce indirizzi guest in indirizzi host tramite strutture dati allocate dinamicamente.
Qui risiede il problema. Nel codice shadow MMU, la funzione kvm_mmu_get_child_sp() riutilizza le shadow page confrontando solo il guest frame number (gfn), l'indirizzo della pagina. Non verifica il role.word, un campo che descrive il tipo di pagina: due tipi diversi di tracking page possono occupare lo stesso indirizzo fisico ma svolgere funzioni distinte. Il riutilizzo errato corrompe le strutture interne di KVM, generando una condizione use-after-free quando una pagina viene liberata e riassegnata prima che il kernel completi la pulizia.
Il meccanismo è puramente in-kernel: non richiede cooperazione da QEMU, libvirt o altro componente userspace. Questo lo rende particolarmente insidioso, perché l'intera superficie di attacco è contenuta nel kernel Linux e non richiede configurazioni complesse dello stack di virtualizzazione.
"the first guest-to-host exploit triggerable on both Intel and AMD, to the best of public knowledge" — Hyunwoo Kim (@v4bel)
Sedici anni nascosto in una riga di codice
Secondo la fonte citata, il commit che introdusse il codice vulnerabile è il 2032a93d66fa, datato agosto 2010, nell'era del kernel 2.6.36. La fix, il commit 81ccda30b4e8, è stata mergiata in mainline il 19 giugno 2026. Tra i due: circa 16 anni, decine di release kernel, e l'evoluzione di KVM da progetto sperimentale a pilastro dell'infrastruttura cloud globale.
La patch è una sola riga: l'aggiunta del controllo role.word al confronto di riutilizzo in kvm_mmu_get_child_sp(). Il maintainer KVM Paolo Bonzini ha firmato il commit. Le versioni kernel che includono la correzione sono state rilasciate il 4 luglio 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260.
NVD non ha ancora assegnato un punteggio CVSS alla vulnerabilità. Il dossier non specifica quando tale assegnazione avverrà.
Panico dell'host ora, code execution con exploit non pubblico
Il PoC rilasciato pubblicamente da Kim causa il panic del kernel host, un denial of service totale che blocca tutte le VM in esecuzione sulla macchina fisica. Kim afferma di avere sviluppato separatamente un exploit non pubblico che converte lo stesso bug in esecuzione di codice arbitrario completo sull'host, ottenendo il controllo della macchina fisica da una VM guest.
L'impatto differenzia tra i due vendor solo nell'ultimo step: il percorso fino al corruption dello shadow MMU è identico su Intel e AMD, ma il pivot finale per il controllo completo richiede lavoro specifico per ciascuna architettura. Quello pubblicato è il terzo disclosure di Kim in circa due mesi, dopo Dirty Frag a maggio 2026.
Il ricercatore ha ricevuto una ricompensa tramite il programma kvmCTF di Google, che offre fino a 250.000 dollari per guest-to-host escapes completi. La fonte non specifica l'ammontare esatto assegnato per Januscape.
Un vettore aggiuntivo su sistemi con /dev/kvm world-writable
La fonte cita un caso di espansione del perimetro di attacco specifico per distribuzioni come RHEL dove il device /dev/kvm è configurato con permessi world-writable (0666). In questa configurazione, lo stesso bug potrebbe essere utilizzato come local privilege escalation: un utente non privilegiato sul sistema host potrebbe teoricamente raggiungere root sfruttando il percorso vulnerabile nel kernel. La fonte non quantifica la diffusione effettiva di questa configurazione o fornisce dettagli tecnici aggiuntivi su questo vettore.
Non è confermato se l'exploit completo per code execution esista effettivamente al di là della dichiarazione del ricercatore. Non è verificato se la vulnerabilità sia stata sfruttata in-the-wild al di fuori dell'ambiente controllato di kvmCTF.
Perché è importante
Il dossier non specifica misure correttive specifiche per gli operatori oltre alla disponibilità delle patch kernel elencate. La fonte non quantifica il numero di sistemi con nested virtualization abilitata per guest non trusted. Non è chiaro se altri ricercatori indipendenti abbiano riprodotto l'exploit completo non pubblico.
ARM64 è esplicitamente escluso da questa vulnerabilità: Januscape colpisce solo l'architettura x86. Il bug KVM/arm64 separato denominato ITScape (CVE-2026-46316) è un problema distinto con il proprio identificatore e proprio meccanismo.
Domande frequenti
La mia VM in cloud è a rischio?
Il percorso di attacco richiede che la VM abbia root e che l'host abbia abilitato la nested virtualization. La maggior parte dei provider cloud pubblici non espone nested virtualization a tenant generici, ma i provider che offrono "bare metal" o istanze dedicate con questa feature abilitata dovrebbero verificare la propria esposizione.
Perché il bug è durato 16 anni senza essere trovato?
Il codice shadow MMU è considerato legacy stabile: viene attraversato solo in condizioni specifiche (nested virtualization), mentre il percorso comune su hardware moderno usa EPT/NPT. Questa biforcazione ha mascherato la vulnerabilità agli audit regolari finché la nested virtualization non è diventata infrastruttura standard.
È verificato che l'exploit completo funzioni davvero?
Il PoC pubblico che causa panic è verificabile. L'exploit per code execution completa è dichiarato dal ricercatore ma non pubblico e non indipendentemente confermato nel dossier.
Fonti
- https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html
- https://windowsforum.com/threads/cve-2026-46131-fixing-linux-kvm-nested-ept-npt-hyper-v-tlb-flush-state-bug.420643/
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=kvm
- https://windowsforum.com/threads/cve-2026-46059-kvm-amd-nested-virtualization-nextrip-save-restore-fix.420322/
- https://windowsforum.com/attachments/windowsforum-cve-2026-46131-fixing-linux-kvm-nested-ept-npt-hyper-v-tlb-flush-state-bug-webp.146971/
- https://data.windowsforum.com/attachments/113/113398-3e20eae4a72062ceea4880bd427a3e7f.jpg?hash=P_54ojjeww
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.