Una vulnerabilità dormiente da 16 anni nel Kernel Linux permette a un attaccante di evadere da una macchina virtuale ed eseguire codice arbitrario sull’host che la ospita. Si chiama Januscape ed è, per stessa ammissione del ricercatore che l’ha scoperta, il primo exploit guest-to-host noto che funziona indistintamente su processori Intel e AMD.

A scoprirla è stato Hyunwoo Kim (aka V4bel), ricercatore di sicurezza già noto per aver reso pubblica a maggio Dirty Frag. La vulnerabilità, tracciata come CVE-2026-53359, è descritta come un use-after-free nel codice della shadow MMU di KVM/x86, il modulo che gestisce la virtualizzazione basata su Kernel per le architetture x86 e x86_64. Kim l’ha dimostrata come zero-day all’interno del programma di bug bounty kvmCTF di Google, che premia fino a 250.000 dollari le vulnerabilità di VM escape complete.

Il codice vulnerabile risale al 2010 (Kernel 2.6.36) ed è stato corretto in mainline il 19 giugno 2026 con il commit 81ccda30b4e8. Sono 16 anni di finestra di exposure per chiunque esponga KVM/x86 con nested virtualization abilitata. Il write-up tecnico pubblicato da Kim entra nel dettaglio del root cause, e vale la pena riassumerlo perché spiega bene perché il bug sia rimasto invisibile così a lungo:

Il problema di fondo sta in una funzione del Kernel, kvm_mmu_get_child_sp(), che si occupa di gestire le pagine di memoria usate da KVM per tradurre gli indirizzi delle VM. Prima della patch, questa funzione decideva se riusare una pagina già esistente guardando solo dove puntava il gfn (guest frame number), cioè quale zona di memoria del guest stava gestendo, ma non controllava anche a cosa serviva quella pagina.

Un attaccante può sfruttare una race condition per far cambiare rapidamente il tipo di una pagina, mentre il puntatore resta lo stesso. Il Kernel non se ne accorge e riusa la pagina sbagliata. Il risultato è che resta in giro un riferimento a una zona di memoria che nel frattempo è stata liberata: quando qualcosa prova ad accedervi, si finisce a leggere o scrivere dati non più validi. È un classico bug use-after-free (molto diffuso nel campo degli attacchi di memory corruption, soprattutto con usi scorretti della funzione malloc), solo che stavolta capita dentro l’hypervisor invece che in un normale programma.

Il PoC pubblico sfrutta la versione più semplice e affidabile di questa corruzione: invece di puntare a esecuzione di codice, fa scattare un controllo di integrità interno del Kernel, causando un panic immediato dell’host in pochi secondi o minuti. Il PoC è un modulo Kernel caricato dentro il guest, che costruisce da sé un nested guest raw: funziona su entrambe le architetture Intel e AMD (con qualche piccola modifica) perché il bug vive nel codice x86 condiviso tra le due.

Un exploit completo che arriva a eseguire codice come root sull’host esiste, ma non è stato reso pubblico.

La Proof Of Concept è disponibile su GitHub con tanto di demo:

Ma quali sono le conseguenze di questa vulnerabilità? Ce lo spiega direttamente il ricercatore:

With guest-side actions alone, an attacker can compromise the host that runs their VM. For example, an attacker who has rented just a single instance on a public cloud could panic the host kernel to take down every other tenant VM on the same physical machine (DoS), or run code with root privilege on the host to take over the host and all the guests on it (RCE).

Con azioni compiute solo lato guest, un attaccante può compromettere l’host che esegue la sua VM. Ad esempio, un attaccante che ha affittato anche una sola istanza su un cloud pubblico potrebbe mandare in panic il Kernel dell’host, buttando giù ogni altra VM tenant sulla stessa macchina fisica (DoS), oppure eseguire codice con privilegi root sull’host, prendendo il controllo dell’host e di tutti i guest che ospita (RCE).

In sostanza basta un singolo utente con una VM Cloud qualsiasi, che sia EC2 o Azure Virtual Machines, indipendentemente dal fatto che l’host giri su AMD o Intel, per eseguire codice a ring 0, e da lì causare un disservizio o addirittura prendere il controllo di tutti gli altri sistemi ospitati sull’hypervisor che ha compromesso. Come si vede nell’immagine sottostante, più si scende nei ring, maggiori sono i privilegi e i permessi che si ottengono sul sistema. Un attacco che compromette il ring 0 permette di far girare le proprie istruzioni arbitrarie a livello Kernel.

Il 4 luglio sono uscite le versioni mainline corrette, ma ogni distro adotta la modifica con i propri tempi. Vale la pena controllare periodicamente gli aggiornamenti del Kernel tramite il package manager e installarli appena disponibili. Chi gestisce host KVM/x86 multi-tenant, come server Proxmox, deve prestare particolare attenzione: in attesa della patch, la raccomandazione è disabilitare la nested virtualization. ARM64 non è affetto da Januscape, perché gestisce la memoria in modo diverso, ma il problema architetturale di fondo resta lo stesso: esiste infatti un bug analogo, separato, chiamato ITScape.

Insomma, come per Dirty Frag, abbiamo l’ennesima dimostrazione che nei componenti core dell’ecosistema Linux, nonostante siano tutti open-source, può nascondersi debito di sicurezza per anni, finché non salta fuori come 0-day.