Quattro exploit pubblici per il kernel Linux mettono a rischio di accesso root locale gli host senza patch

La disponibilità di codice funzionante rende urgente intervenire

Il ricercatore di sicurezza Asim Manizada ha pubblicato il 18 settembre 2026 i dettagli tecnici e exploit funzionanti per quattro vulnerabilità del kernel Linux in grado di elevare i privilegi locali fino a root.

Le vulnerabilità sono DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) e DiagSpill (CVE-2026-74469). Ognuna interessa una parte diversa dello stack di rete del kernel, ma tutte e quattro coinvolgono una gestione non sicura della memoria all’interno di codice altamente privilegiato.

Manizada ha segnalato le vulnerabilità al team di sicurezza del kernel Linux a metà luglio. In seguito si è coordinato con le distribuzioni Linux prima di pubblicare gli exploit, dando ai manutentori il tempo necessario per distribuire le correzioni.

Non sono stati segnalati casi di sfruttamento nel mondo reale. Tuttavia, la disponibilità pubblica del codice offre agli attaccanti una base da cui adattare le tecniche ai kernel delle distribuzioni non aggiornati, soprattutto su server multiutente, infrastrutture condivise e host che eseguono container.

Gli exploit pubblicati sono messi a punto per build specifiche del kernel e possono mandare in crash i sistemi bersaglio. È più corretto considerarli strumenti di ricerca proof-of-concept che impianti affidabili, ma durante i test Manizada ha sfruttato con successo le vulnerabilità sottostanti per ottenere shell root.

Quattro bug in quattro sottosistemi di rete

DirtyAH6 interessa l’implementazione dell’Authentication Header di IPsec per IPv6. Il codice vulnerabile riordina gli indirizzi in un routing header IPv6 prima di calcolare o validare l’Integrity Check Value.

Il problema nasce dal fatto che ipv6_rearrange_rthdr() si fidava del campo segments_left del routing header senza verificare che corrispondesse al numero di indirizzi indicato da hdrlen. In un pacchetto IPv6 raw HDRINCL, hdrlen può indicare un indirizzo mentre segments_left contiene un valore molto più grande. Impostandolo a 255, un puntatore interno agli indirizzi viene spostato indietro di 4.064 byte, creando un accesso alla memoria fuori dai limiti e una potenziale scrittura.

TUNderflow risiede nel codice di rete virtuale TUN/TAP. All’interno di tun_get_user(), il kernel usava tun->align sia come spazio di riserva nell’header del socket buffer sia in un calcolo che determinava la quantità di dati del pacchetto da mantenere in forma lineare.

Open vSwitch può fornire da un’altra porta una richiesta di spazio di riserva nell’header di dimensioni eccessive. Se il valore supera l’area utilizzabile nell’header di un socket buffer di una pagina, SKB_MAX_HEAD(align) va in underflow. Un valore intermedio negativo può successivamente subire un wrapping quando viene assegnato a un size_t senza segno, consentendo a tun_alloc_skb() di posizionare skb->data al di fuori del buffer allocato.

TUNderflow ha un punteggio CVSS 3.1 pari a 7,8, con il vettore CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

PPPoEject interessa PPP over Ethernet. In pppoe_sendmsg(), il kernel salvava un puntatore a un header PPPoE e richiamava poi dev_hard_header(). I callback specifici del dispositivo possono espandere o riallocare l’header del socket buffer, invalidando i puntatori alla memoria originale.

Una sequenza di attivazione prevede un’operazione di invio bloccata in copy_from_user() mentre la prima porta non Ethernet viene aggiunta a un dispositivo team vuoto. Un callback delegato per l’header GRE può quindi spostare il buffer. In seguito PPPoE scrive sei byte attraverso il puntatore obsoleto nella memoria liberata, generando una condizione use-after-free.

Anche PPPoEject ha un punteggio di 7,8 secondo CVSS 3.1, con CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

DiagSpill è una vulnerabilità di overflow di un contatore in sctp_diag. La funzione sctp_assoc_add_peer() incrementa un transport_count a 16 bit per ogni peer SCTP univoco. L’aggiunta del 65.536° transport fa tornare il contatore a zero.

Il codice diagnostico SCTP riserva quindi un payload INET_DIAG_PEERS basandosi su quel valore nullo, ma copia comunque ogni struttura contenuta in transport_addr_list. Il risultato è una scrittura fuori dai limiti di circa 8 MiB oltre la coda del socket buffer. La correzione rifiuta i nuovi peer univoci quando transport_count raggiunge U16_MAX.

DiagSpill ha il punteggio più alto dei quattro: 8,8, con CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Per DirtyAH6 non sono disponibili un punteggio o un vettore CVSS v3.

Requisiti di accesso locale e impatto remoto limitato

DirtyAH6, TUNderflow e PPPoEject richiedono normalmente che siano abilitati gli user namespace non privilegiati. Questa funzionalità consente a un account comune di acquisire capacità simili a quelle di root all’interno di uno namespace isolato, comprese quelle necessarie per accedere a percorsi di rete altrimenti soggetti a restrizioni.

Di conseguenza, le tre vulnerabilità sono particolarmente rilevanti nei contesti in cui gli utenti locali possono creare namespace propri. Disabilitare questa funzionalità può rimuovere il punto d’ingresso previsto per gli utenti non privilegiati, ma non protegge i processi o i container che dispongono già delle necessarie capacità di amministrazione della rete.

DiagSpill è diverso. Manizada lo ha descritto come una vulnerabilità che non richiede né user namespace né privilegi speciali. Il vettore NVD assegna tuttavia PR:L, indicando che nel relativo modello di valutazione sono richiesti privilegi ridotti. Il motivo di questa discrepanza non è noto.

L’impatto remoto è più limitato rispetto al rischio di ottenere root localmente. DirtyAH6 può mandare in crash un router o un gateway IPv6 che instrada traffico IPv6 e aggiunge un’Authentication Header IPsec in modalità transport. Manizada ha ottenuto root da remoto solo dopo aver preparato deliberatamente la memoria del bersaglio in laboratorio e ha valutato come estremamente difficile lo sfruttamento senza tale preparazione.

DiagSpill può mandare da remoto un sistema in crash quando sono attive le relative opzioni SCTP non predefinite. Non è stato individuato alcun percorso praticabile verso root da remoto, neppure ipotizzando condizioni favorevoli nella disposizione della memoria.

Non è stato segnalato alcun percorso diretto di sfruttamento remoto per TUNderflow o PPPoEject. In teoria, le vulnerabilità potrebbero consentire una fuga da un container, ma non è stato sviluppato né dimostrato alcun caso del genere.

Le correzioni complete partono da specifiche release stable

I manutentori del kernel Linux hanno corretto tutti e quattro i difetti. Le prime release stable upstream segnalate come contenenti l’insieme completo delle patch sono:

• 5.10.270
• 5.15.221
• 6.1.188
• 6.6.157
• 6.12.109
• 6.18.50
• 7.2.4

Questi numeri non devono essere confrontati meccanicamente con le stringhe del kernel riportate da Debian, Ubuntu, Red Hat, SUSE o altre distribuzioni. I vendor eseguono spesso il backport delle patch di sicurezza mantenendo numeri di versione di base più vecchi.

Gli amministratori devono verificare che il pacchetto del kernel della propria distribuzione includa le correzioni per tutti e quattro i CVE. Non sono noti gli intervalli esatti delle versioni vulnerabili, le versioni dei pacchetti delle distribuzioni né gli identificativi degli advisory dei vendor.

Nessuna delle quattro vulnerabilità risulta associata a una voce nel catalogo CISA Known Exploited Vulnerabilities o a una scadenza di remediation KEV. Il dato è coerente con l’assenza di attacchi segnalati, ma non riduce l’esposizione creata dalla disponibilità pubblica del codice degli exploit.

Quali sistemi devono avere la priorità

L’applicazione delle patch dovrebbe iniziare dai sistemi in cui utenti non attendibili possono eseguire codice localmente o creare namespace. Tra gli obiettivi prioritari rientrano le piattaforme di hosting condiviso, i server di ricerca, le macchine di sviluppo, gli host che eseguono container e altri ambienti Linux multiutente.

L’esposizione è inoltre maggiore dove le funzionalità di rete interessate vengono utilizzate attivamente, tra cui Open vSwitch, TUN/TAP, PPPoE, IPsec AH6, SCTP, i dispositivi team e la gestione delegata degli header GRE.

Come misure temporanee di riduzione del rischio, gli amministratori possono disabilitare gli user namespace non privilegiati e rimuovere le funzionalità di rete inutilizzate. Disabilitare IPv6 AH6, TUN/TAP, PPPoE o SCTP può rendere irraggiungibili specifici percorsi vulnerabili.

Questi controlli non sostituiscono i kernel aggiornati. Potrebbero esistere percorsi alternativi di esecuzione e DiagSpill non viene neutralizzato disabilitando gli user namespace.

Il monitoraggio dovrebbe concentrarsi sulla creazione inattesa di namespace, su nuove configurazioni TUN/TAP o SCTP, su attività insolite di Open vSwitch e dei dispositivi team, su shell root inspiegabili e sui crash del kernel che coinvolgono i sottosistemi interessati. Poiché i proof-of-concept possono destabilizzare un host, i fault del kernel possono essere un primo segnale di test o di un tentativo di sfruttamento fallito.

La ricerca assistita dall’AI ha individuato errori vecchi di decenni

Manizada ha utilizzato un’analisi personalizzata assistita dall’AI per modellare il comportamento della memoria del kernel e ragionare sulla disposizione degli oggetti. La correzione di DirtyAH6 include un’attribuzione “Assisted-by” relativa a questo strumento.

Si stima che gli errori di programmazione alla base delle vulnerabilità abbiano un’età compresa tra 10 e 21 anni. Comprendono un campo del pacchetto non verificato, un underflow di un intero seguito da un wrapping senza segno, un puntatore obsoleto conservato durante la riallocazione del buffer e l’overflow di un contatore a 16 bit.

A luglio Manizada aveva inoltre divulgato la vulnerabilità OVSwrap di Open vSwitch. Uno dei nuovi exploit riutilizza una tecnica di Dirty Frag, un’altra vulnerabilità del kernel Linux che consente di ottenere root e che era stata divulgata da un altro ricercatore a maggio.

L’affidabilità degli exploit pubblici rimane oggi limitata. Lo sviluppo più significativo è che gli attaccanti possono ora studiare percorsi completi di sfruttamento per quattro bug di rete privilegiati e adattarli ai kernel delle distribuzioni ampiamente utilizzate. Applicare le patch chiude questa opportunità in modo più affidabile rispetto al solo contenimento basato sulla configurazione.