PwnEscape rompe KVM dal networking Linux: una VM può leggere l’host

🛡️ Executive Summary

• PwnEscape sfrutta metadati di checksum controllabili dal guest per modificare un header IPv4 dopo che il kernel lo ha già validato.
• I ricercatori hanno dimostrato una disclosure ripetibile di 32 byte della memoria host e, sui propri sistemi KVM, una catena completa fino all’esecuzione root sull’host.
• La falla è stata individuata con ricerca assistita da AI, ma il risultato è stato validato sperimentalmente e non equivale a un’automazione autonoma dell’exploitation.

PwnEscape sposta nuovamente il problema dell’isolamento KVM fuori dal solo hypervisor. CVE-2026-99999 nasce infatti nel networking del kernel Linux e permette a un guest controllato dall’attaccante di influenzare metadati utilizzati successivamente dall’host, fino a provocare una lettura di memoria oltre i dati logicamente appartenenti al pacchetto. La ricerca arriva dopo settimane nelle quali il caso Vercel era ancora descritto pubblicamente come possibile VM escape senza CVE né dettagli tecnici. La disclosure completa chiarisce ora il meccanismo: non viene violato direttamente KVM, ma una relazione di fiducia tra checksum differito, header IPv4 già validato e successive operazioni del kernel.

PwnEscape modifica l’header IPv4 dopo che Linux lo ha già validato

La ricerca tecnica pubblicata da pwn.ai descrive un problema nel trattamento di pacchetti marcati CHECKSUM_PARTIAL, meccanismo normale attraverso cui Linux può rimandare il calcolo del checksum a una fase successiva. Il punto critico è che parametri come csum_start e csum_offset non descrivono soltanto il pacchetto: indicano anche dove il kernel dovrà effettuare successivamente una scrittura. I ricercatori hanno mostrato che metadati provenienti da un contesto meno affidabile possono sopravvivere a trasformazioni del pacchetto e diventare incoerenti rispetto alla posizione reale dell’header di rete. Il kernel analizza quindi un header IPv4 considerandolo valido, prende decisioni di routing e frammentazione e soltanto dopo completa il checksum. In quella fase la scrittura differita può ricadere dentro l’header già interpretato e modificarne il campo IHL. Nel caso dimostrato, il primo byte passa concettualmente da 0x45, cioè IPv4 con header da 20 byte, a 0x4f, che indica un header da 60 byte. Non c’è una race condition tradizionale: il kernel valida una rappresentazione del pacchetto e ne consuma successivamente un’altra, modificata da un’operazione che lui stesso esegue.

Leggi anche: Atlassian chiude una falla critica, KVM ed Exchange sotto esame

Trentadue byte per pacchetto trasformano il bug in una perdita di memoria host

La conseguenza più immediata è una host-memory disclosure ripetibile. Nel test documentato il buffer lineare contiene logicamente 28 byte: 20 dell’header IPv4 originale e otto di payload. Dopo la modifica tardiva del campo IHL, il frammentatore ritiene però di avere davanti un header da 60 byte e tratta come opzioni IPv4 anche dati successivi. Otto byte appartengono ancora al payload legittimo; i successivi 32 byte escono invece dal contenuto logico del pacchetto e provengono dalla memoria dell’host. Linux può inserirli nell’header dei frammenti trasmessi e renderli quindi osservabili dal guest.

Questa distinzione è importante: non è necessario dimostrare una lettura oltre l’intera allocazione fisica dello slab perché esista una violazione di confidenzialità. È sufficiente che il kernel restituisca al tenant dati che non appartengono al suo pacchetto né al suo dominio di fiducia. Negli ambienti multi-tenant il valore della vulnerabilità nasce proprio da questo: il guest ottiene un oracolo sulla memoria del sistema che dovrebbe isolarlo.

Dal memory leak al root dell’host, ma soltanto nei test controllati

La ricerca va oltre il leakage, ma mantiene una distinzione essenziale tra ciò che è stato dimostrato sulla produzione Vercel e ciò che è stato ottenuto nei sistemi dei ricercatori. Nelle sandbox Vercel è stata verificata la capacità di recuperare memoria dell’host. La catena completa è stata invece sviluppata su infrastrutture KVM controllate da pwn.ai: partendo dalle informazioni ottenute attraverso la lettura, il team ha costruito scritture selettive da 64 byte nella memoria del kernel host e le ha utilizzate per eseguire un helper con privilegi root, facendo restituire alla VM un marker generato dall’host. La catena è stata riprodotta dopo quattro cold boot separati. Non equivale quindi a sostenere che sui sistemi Vercel sia stata ottenuta esecuzione root in produzione. È precisamente la cautela che mancava quando il possibile zero-day KVM era emerso inizialmente: oggi esistono una causa tecnica, una primitiva di lettura dimostrata e un escape completo su sistemi posseduti dai ricercatori, ma i tre livelli di prova non devono essere fusi in un’unica affermazione.

Il bug non è in KVM ma nel confine attraversato dal guest

PwnEscape è particolarmente interessante perché mostra un limite della lettura tradizionale delle vulnerabilità di virtualizzazione. La macchina virtuale non interagisce soltanto con il codice dell’hypervisor: raggiunge networking, device emulation, memory allocator, filtri, API e componenti del sistema operativo host. In questo caso il problema è una forma di trust inversion nei metadati differiti. Informazioni provenienti da un’origine non fidata vengono validate rispetto a una rappresentazione iniziale, il pacchetto viene trasformato, un’operazione rinviata modifica dati già considerati affidabili e un componente successivo consuma il nuovo stato senza ristabilire l’invariante. È un modello differente da Zapscape, che colpiva direttamente la shadow MMU di KVM/x86, e dalla successiva vulnerabilità KVM/Arm64 legata alla nested virtualization. Il risultato però converge sullo stesso punto: il confine guest-host può cedere anche quando KVM in senso stretto non contiene il bug che avvia la catena.

La patch protegge cinque percorsi IPv4 ma non ridisegna tutto il checksum

La correzione upstream è identificata dal commit 6785011f8b16, ipv4: validate checksum_start before completing checksum, confluito nel ramo principale del kernel il 14 ottobre. Il fix introduce ip_check_csum_start() e verifica che l’inizio del checksum si trovi almeno oltre la fine dell’header IPv4 prima che il kernel completi l’operazione differita. Il controllo viene applicato a cinque punti nei quali poteva essere eseguito il checksum. La proprietà cercata è semplice: una scrittura destinata al checksum non deve poter ricadere dentro un header di rete già validato. La stessa ricerca chiarisce però che il commit rappresenta una misura di defence in depth e non una riprogettazione completa dell’ingresso dei metadati virtio. Durante la revisione sono emerse questioni più ampie sul modo in cui checksum e trasformazioni dei pacchetti vengono validati, che restano separate dalla primitiva specificamente dimostrata da PwnEscape. Per gli amministratori significa applicare un kernel nel quale la correzione sia stata backportata dal proprio vendor e assicurarsi che sia l’host, non soltanto il guest, a eseguire il kernel corretto.

Continua con:

Debian 13 corregge Zapscape, SCTPhantom e altre 26 falle del kernel

Zero-day e vulnerabilità critiche tra VeloCloud, SharePoint, KVM, Defender e D-Link

L’AI ha trovato PwnEscape ma la prova resta nelle mani dei ricercatori

PwnEscape contiene infine un elemento destinato a pesare sulla ricerca offensiva. Pwn.ai dichiara di avere utilizzato Omega-Pwn, infrastruttura sperimentale che mantiene stato, ipotesi, tracce del codice ed esperimenti durante campagne di ricerca lunghe, con GPT-5.6 Sol impiegato come principale motore di ragionamento per l’analisi sorgente. Il team attribuisce alla ricerca tre giorni per arrivare alla primitiva iniziale e meno di 700 dollari di consumo API, ma precisa anche che gli esseri umani hanno definito il perimetro, guidato l’indagine, contestato i risultati e validato ogni passaggio sul comportamento reale del kernel. È un dettaglio più importante del claim “AI trova zero-day”. Già nel 2026 exploit contro il kernel Linux sviluppati con assistenza AI avevano mostrato che i modelli possono accelerare source review e ricerca delle primitive. PwnEscape alza l’asticella perché collega quella capacità a una vulnerabilità nel cuore dell’isolamento cloud. Il collo di bottiglia, però, resta la validazione: il modello può ampliare lo spazio esplorato, ma una vulnerabilità diventa conoscenza di sicurezza soltanto quando ipotesi, leak, scritture e impatto vengono dimostrati separatamente su sistemi reali.