Quattro exploit Linux pubblicati: root locale con bug vecchi di 10-21 anni

Il ricercatore di sicurezza Asim Manizada ha pubblicato il 18 settembre 2026 quattro exploit proof-of-concept funzionanti per altrettante vulnerabilità del kernel Linux che permettono escalation di privilegi locali fino a root. I bug, denominati DirtyAH6, TUNderflow, PPPoEject e DiagSpill, hanno tra 10 e 21 anni di presenza nel codice e sono stati individuati con un processo di ricerca assistito da intelligenza artificiale. Le patch sono disponibili nelle versioni kernel upstream da 5.10.270 a 7.2.4, ma la pubblicazione dei PoC abbassa drasticamente la soglia di weaponization per gli attaccanti.

DirtyAH6: out-of-bounds write nell'header IPv6

Il primo flaw, CVE-2026-80844, risiede nel sottosistema IPsec del kernel. La funzione ipv6_rearrange_rthdr() non verifica che il campo segments_left corrisponda effettivamente agli indirizzi presenti nell'header di routing IPv6. Questo disallineamento permette di scrivere al di fuori dei limiti del buffer allocato.

Secondo la ricostruzione di The Hacker News, Manizada ha valutato la possibilità di sfruttamento remoto come estremamente limitata. La citazione diretta del ricercatore è chiara: "looks extremely difficult". Il percorso remoto richiede condizioni ristrette — un router IPv6 con AH transport mode configurato — e anche in quel caso si riduce a crash denial-of-service, non a remote root. L'escalation a root resta un percorso locale.

TUNderflow e PPPoEject: due facce della corruzione di memoria

CVE-2026-81000, battezzato TUNderflow, sfrutta un integer underflow nel driver TUN/TAP. Il valore di receive-headroom viene riutilizzato come dimensione di allocazione, ma quando Open vSwitch fornisce un valore oversize il calcolo size_t scende sotto zero e il kernel alloca un buffer di dimensioni errate. La corruzione di memoria segue immediatamente.

CVE-2026-68121, PPPoEject, è un use-after-free nel sottosistema PPPoE. Il kernel mantiene un puntatore attraverso la chiamata a dev_hard_header(), ma questa funzione può liberare e riallocare il buffer in modo trasparente per il chiamante. Il puntatore d'appoggio diventa dangling, consentendo accesso a memoria già rilasciata.

Entrambi richiedono unprivileged user namespaces per raggiungere la condizione di exploit completo. La configurazione è abilitata by default in molte distribuzioni Linux moderne, inclusi ambienti containerizzati e hosting condiviso.

DiagSpill: l'eccezione pericolosa che non ha bisogno di user namespaces

CVE-2026-74469 è il flaw più grave per impatto potenziale. Il punteggio CVSS 8.8 — assegnato secondo le metriche riportate da SecurityOnline.info — riflette una superficie di attacco più ampia: il vettore è network, con privilegi bassi e senza interazione utente.

Il meccanismo è un integer overflow nel sottosistema SCTP diag. Un counter a 16 bit effettua wrap a 65.536, inducendo sctp_diag a riservare zero byte di spazio mentre copia l'intera lista di associazioni. Il risultato è un heap overflow massivo di circa 8 MiB. Secondo il dossier, questo bug è raggiungibile senza unprivileged user namespaces, eliminando un intero strato di mitigazione che protegge gli altri tre flaw.

Manizada ha riportato che né AppArmor né SELinux hanno bloccato gli exploit nei test condotti. La citazione, tratta da SecurityOnline.info, è testuale: "AppArmor and SELinux did not block the exploits in testing".

"this batch likely ends the public phase of his AI-assisted bug hunting" — Asim Manizada, citato da The Hacker News

La firma AI nel commit di patch

Un dettaglio distintivo emerge dall'analisi della catena di attribuzione. Il commit di correzione per DirtyAH6 contiene una riga 'Assisted-by' che accredita esplicitamente il tooling di intelligenza artificiale utilizzato nella ricerca. Questo non è una nota a margine: è la prima traccia documentata nel flusso di sviluppo del kernel Linux dove il processo di discovery è formalmente riconosciuto nell'attribuzione del fix.

La metodologia di Manizada, descritta nei dettagli pubblicati da The Hacker News, mappa la gestione della memoria nel kernel e applica ragionamento strutturato sul layout degli oggetti — un approccio che il ricercatore stesso indica come conclusione della sua fase pubblica di bug hunting AI-assisted.

Il patching come inseguimento: versioni e distribuzioni

Le patch sono disponibili upstream nelle versioni 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 e 7.2.4, secondo la tabella riassuntiva pubblicata da SecurityOnline.info. I commit hash specifici sono identificati per ciascun flaw.

Le fonti citano esclusivamente versioni kernel upstream. Non emergono informazioni su quali distribuzioni Linux abbiano già rilasciato pacchetti patchati nei propri repository: il ritardo tra upstream release e disponibilità nei canali delle distro è una variabile non quantificata nel dossier. I sistemi che tracciano il kernel vanilla con ritmo di aggiornamento rapido sono coperti; le installazioni con supporto a lungo termine e cicli di backport più conservativi accumulano esposizione.

Cosa fare adesso

• Verificare la versione del kernel in esecuzione e confrontarla con le release patchate: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50, 7.2.4.
• Disabilitare unprivileged user namespaces dove non strettamente necessario, mitigando il percorso d'attacco per DirtyAH6, TUNderflow e PPPoEject.
• Monitorare i repository delle distribuzioni in uso per il rilascio di pacchetti kernel aggiornati: la presenza delle patch upstream non implica disponibilità immediata nei canali della distro.
• Applicare le patch con priorità su server multi-utente, hosting condiviso, ambienti container e istanze cloud dove un attaccante con accesso limitato può tentare escalation a root.

Perché la timeline pubblicazione-segnalazione è critica

Manizada ha notificato le vulnerabilità a security@kernel.org a metà luglio 2026. L'intervallo di circa due mesi tra segnalazione responsabile e pubblicazione dei PoC è compatibile con i cicli di sviluppo del kernel, ma crea una finestra di esposizione misurata: i sistemi non aggiornati prima del 18 settembre sono ora confrontati con exploit pubblici e verificati, non con teorie d'attacco.

Il rischio non è teorico. La combinazione di PoC funzionanti, bug con superficie di attacco estesa (DiagSpill senza user namespaces) e mancato blocco da parte dei principali sistemi di mandatory access control indica che le barriere residue sono interamente nel patching, non nella mitigazione runtime.

Domande frequenti

Cesono conferme di sfruttamento in-the-wild?

No. Il dossier non documenta attacchi reali osservati: la minaccia attuale deriva dalla disponibilità pubblica degli exploit PoC, che riduce il tempo e la competenza necessari per la weaponization.

Perché CVE-2026-74469 ha CVSS più alto degli altri?

Il vettore di attacco è network (AV:N) contro locale (AV:L) per gli altri tre, con stessa complessità di attacco e stesso impatto sulla triade CIA. Questa differenza nel vettore sposta il punteggio da 7.8 a 8.8.

L'AI-assisted discovery cambia il volume di vulnerabilità attese?

Manizada stesso indica questa pubblicazione come conclusione della fase pubblica del suo lavoro AI-assisted. Il dato non permette di generalizzare su altri ricercatori o su trend di volume, ma documenta che il tooling AI ha prodotto risultati concreti su codepath decennali non precedentemente analizzati sistematicamente.

Fonti

• https://thehackernews.com/2026/09/public-exploits-released-for-four-linux.html
• https://securityonline.info/linux-kernel-lpe-quartet-disclosed/
• https://blog.netmanageit.com/public-exploits-released-for-four-linux-kernel-flaws-that-enable-local-root/
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence
• https://thehackernews.com/search/label/Vulnerability
• https://thehackernews.com/search/label/Cyber%20Attack