Una vulnerabilità nel codice TCP del kernel Linux, identificata come CVE-2026-98432, può causare letture di memoria già liberata durante nuove connessioni IPv4. Il team CVE del kernel le attribuisce un punteggio CVSS di 9,8 su 10, mentre Ubuntu e Red Hat Enterprise Linux non hanno ancora pubblicato un kernel corretto.
Anthropic afferma di aver realizzato con Claude un exploit capace di ottenere l’esecuzione di comandi come root da remoto, senza credenziali, ma il test ha riguardato server con un listener Multipath TCP (MPTCP). Al momento non risultano attacchi documentati che sfruttino il difetto.
Un race condition nel handshake TCP
Il problema riguarda il modo in cui Linux prepara le nuove connessioni TCP IPv4. Al completamento dell’handshake, il kernel trasferisce al nuovo socket alcune opzioni IP associate alla richiesta in attesa senza copiarle.
Se quel socket viene distrutto mentre un’altra CPU sta ancora consultando le opzioni per rispondere a una richiesta di connessione ritrasmessa, il kernel può accedere a memoria già liberata: è il comportamento noto come use-after-free.
La falla sarebbe presente dal kernel Linux 4.4. La correzione, applicata dagli sviluppatori del kernel il 5 ottobre, fa attendere la liberazione della memoria finché le altre CPU non hanno terminato di leggere le opzioni. Il difetto non coinvolge IPv6, dove quelle opzioni vengono copiate.
Perché i punteggi di gravità non coincidono
Il punteggio 9,8 del team CVE del kernel considera un attaccante in grado di inviare una richiesta TCP con opzioni IPv4 Record Route o Timestamp e poi ritrasmetterla per tentare di vincere la gara tra le operazioni. In questo scenario, la falla potrebbe esporre memoria vicina, corrompere memoria del kernel o mandare in crash il sistema.
Red Hat valuta invece la vulnerabilità 5,9 nella sua pagina CVE, classificandola Moderate perché la gara sarebbe difficile da vincere e il risultato più probabile sarebbe il crash del kernel. Un advisory leggibile dalle macchine di Red Hat, aggiornato il 29 ottobre, la indica però come Important con punteggio 8,1. Oracle e SUSE usano lo stesso valore di 8,1, mentre Amazon la valuta 7,0.
L’exploit descritto da Anthropic
Nel post del 27 ottobre, Anthropic ha spiegato che Claude avrebbe scritto l’exploit dopo un prompting iniziale. La prima fase sfrutterebbe la race condition per indurre il kernel a restituire byte aggiuntivi; ottenendo un indirizzo del kernel, l’attaccante potrebbe aggirare KASLR, la randomizzazione degli indirizzi in memoria.
La seconda fase, sempre secondo Anthropic, userebbe il difetto per sovrascrivere un puntatore callback con l’indirizzo di un payload già collocato nella memoria del kernel. Quando il kernel richiama quel puntatore, il payload eseguirebbe un comando scelto dall’attaccante con privilegi root.
La società riferisce che, nel proprio test, l’ottenimento di un indirizzo del kernel ha richiesto 48 minuti e l’esecuzione di comandi altri 5 minuti. Non ha però pubblicato il codice dell’exploit, la versione del kernel né la configurazione usata. Inoltre, il post parla di server con listener MPTCP e non chiarisce se la stessa compromissione sia possibile su server che non lo utilizzano.
Patch disponibili, ma non per tutti
Anthropic sostiene che la correzione sia stata integrata a monte e riportata su tutti i rami stabili ancora mantenuti. Per chi usa una distribuzione, tuttavia, il fix arriva soltanto quando il fornitore pubblica il relativo pacchetto kernel.
Debian, Oracle Linux, SUSE e Amazon Linux hanno già distribuito pacchetti corretti almeno per parte dei loro kernel. Ubuntu segnala come vulnerabili o in lavorazione anche kernel cloud, FIPS e real-time; Red Hat afferma che gli aggiornamenti sono rinviati a una versione futura. Nessuna delle due distribuzioni indica una data di rilascio.
Per chi compila il kernel autonomamente, la correzione è presente in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3. Il team CVE del kernel raccomanda l’aggiornamento all’ultima versione stabile e non supporta il cherry-picking delle singole patch.
FAQ
Ci sono attacchi già confermati?
No. Al 29 ottobre, gli advisory dei fornitori, il record CVE e il post di Anthropic non riportavano attacchi in corso o già osservati. La vulnerabilità non compariva neppure nella copia del catalogo CISA Known Exploited Vulnerabilities aggiornata da CIRCL il 28 ottobre.
Disabilitare MPTCP risolve il problema?
Non è possibile affermarlo sulla base delle informazioni disponibili. L’exploit descritto da Anthropic prende di mira un listener MPTCP, ma gli advisory e il post non dicono se disattivare Multipath TCP riduca effettivamente il rischio.
Qual è l’azione indicata per gli amministratori?
Dove è disponibile un kernel corretto, l’indicazione è installarlo. Per Ubuntu, RHEL e alcune versioni di Amazon Linux e SUSE senza pacchetto aggiornato, le fonti non riportano mitigazioni considerate semplici, adatte alla maggior parte delle installazioni e stabili.
Considerazioni finali
La distanza tra il 9,8 assegnato dal team del kernel e le valutazioni più caute dei fornitori non rende la falla irrilevante: mostra piuttosto quanto il rischio dipenda dalla riproducibilità della race condition e dalla configurazione esposta. Il fatto che un exploit descritto pubblicamente punti ai listener MPTCP impone di distinguere il potenziale tecnico dalla portata effettiva sulle installazioni comuni.
Il punto più urgente resta la disponibilità disomogenea degli aggiornamenti. Una patch già presente nei rami stabili è utile solo quando arriva nei pacchetti della distribuzione usata: per Ubuntu e RHEL, che non hanno ancora indicato una data, è questa l’informazione che pesa di più.