Allarme rosso per nuova vulnerabilità critica nel kernel Linux (TCP su IPv4): Ubuntu e RHEL non hanno ancora la patch (aggiornato: 29 ottobre 2026, ore 22:50)

Un pacchetto SYN con qualche opzione IP in più, ritrasmesso nel momento giusto. In teoria basta questo per mettere in difficoltà il codice che gestisce l'handshake TCP su IPv4 nel kernel Linux. La vulnerabilità CVE-2026-98432 è un use-after-free che il team CVE del kernel ha valutato con un punteggio CVSS di 9,8. Anthropic sostiene di averla trasformata in un exploit che esegue comandi come root da remoto. Ubuntu e Red Hat Enterprise Linux non hanno ancora distribuito una correzione, mentre altre distribuzioni hanno già aggiornato i propri kernel. Chi amministra sistemi Linux ha quindi un problema concreto: deve capire quanto è esposto e come organizzarsi in attesa della patch.

Una race condition nell'handshake TCP su IPv4

Il difetto si trova in tcp_v4_syn_recv_sock(). Quando l'handshake si completa, le opzioni IP memorizzate nella richiesta in sospeso (ireq->ireq_opt) passano al nuovo socket figlio (newinet->inet_opt) senza essere copiate. Due oggetti puntano dunque alla stessa area di memoria. Le richieste in sospeso vengono elaborate senza il lock del socket in ascolto, e questo avviene dal commit 079096f103fa (tcp/dccp: install syn_recv requests into ehash table). Così una seconda CPU, mentre gestisce un SYN ritrasmesso, può leggere quelle opzioni passando per tcp_check_req() → tcp_v4_send_synack() → ip_options_build(). Nello stesso momento la prima CPU le libera con un semplice kfree().

Secondo il record CVE, il bug è presente da Linux 4.4, quindi raggiunge praticamente ogni kernel ancora mantenuto dalle distribuzioni. Fa eccezione RHEL 7: Red Hat precisa che il suo kernel non ha mai ricevuto il codice vulnerabile. IPv6 è escluso dalla race principale, perché tcp_v6_syn_recv_sock() copia le opzioni. Condivide però un secondo problema, legato alla migrazione dei socket di richiesta, limitato alle opzioni CALIPSO e destinato a una patch separata.

Anche questa seconda race ha un perimetro preciso. Si manifesta solo con net.ipv4.tcp_migrate_req=1 oppure con un programma eBPF di tipo BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. La documentazione del kernel indica tcp_migrate_req come disattivato per impostazione predefinita.

Dal crash al root: le affermazioni di Anthropic

La vulnerabilità è raggiungibile via rete, senza credenziali e senza interazione dell'utente. La complessità viene giudicata bassa perché entrambi i lati della race sono provocati dall'attaccante. Una race vinta può causare tre effetti: memoria del kernel adiacente che finisce nel SYNACK, scritture fuori dai limiti oppure un crash del sistema.

Anthropic si spinge oltre. Secondo l'azienda, un modello di ricerca interno della famiglia Claude, non ancora rilasciato, ha scritto un exploit zero-click. Questo exploit permette a un attaccante remoto senza credenziali di eseguire comandi come root su server Linux con un listener multipath TCP. Va però precisato che né il record CVE né la correzione nel kernel menzionano MPTCP. Il codice vulnerabile è quello dell'handshake TCP su IPv4.

L'attacco descritto da Anthropic ha due fasi. Nella prima, la race viene vinta più volte, finché il kernel legge un campo di lunghezza controllato dall'attaccante e restituisce memoria in eccesso nelle risposte. Da quella memoria si ricava un puntatore che neutralizza KASLR. Nella seconda, un buffer overflow sovrascrive un puntatore a callback ed esegue il payload come root. Servono 48 minuti per ottenere l'indirizzo del kernel e altri 5 per arrivare all'esecuzione di comandi. C'è poi un dettaglio che pesa: una race persa fa fallire solo quel tentativo di connessione, senza mandare in crash il server. L'attaccante, quindi, può riprovare quanto vuole. Queste affermazioni provengono dalla sola Anthropic e non risultano verificate in modo indipendente.

La segnalazione porta la firma di Xinyang Ge, ricercatore di Anthropic. La patch è stata scritta da Eric Dumazet e chiude anche il percorso della migrazione.

9,8 o 5,9? I distributori non sono d'accordo

Il 9,8 "critico" è il punteggio CVSS 3.1 assegnato dal team CVE del kernel. Il tracker di Ubuntu riprende lo stesso valore, con priorità "high". Altrove i numeri scendono: Oracle e SUSE indicano 8,1, Amazon 7,0. Per Red Hat i dati pubblicati vanno da 8,1 a 5,9 "Moderate". Quest'ultimo valore usa il vettore CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, che considera solo l'impatto sulla disponibilità, senza effetti su riservatezza e integrità.

La motivazione dei distributori è sempre la stessa: la race è difficile da vincere, quindi la complessità d'attacco va considerata alta. Il disaccordo riguarda i vettori CVSS, non la natura del bug. L'exploit rivendicato da Anthropic, però, si basa proprio sulla possibilità di ripetere il tentativo all'infinito.

Chi ha la patch e chi no

La correzione upstream è il commit e3f33b0a1d89d738e2b913dab519226eaf76e15b, entrato nel kernel 7.3-rc7. Rimanda la liberazione delle opzioni IP alla fine di un grace period RCU. Una fonte elenca i backport per i rami stabili 6.8.y, 6.17.y e 7.0.y. Un'altra afferma che il fix è presente in ogni kernel stabile upstream ancora mantenuto.

Sul fronte delle distribuzioni, Debian, Oracle Linux, Amazon Linux e SUSE hanno già distribuito kernel corretti, almeno per una parte delle loro release.

Ubuntu, invece, indica tutte le release supportate come vulnerabili e non fornisce una data per il fix. Red Hat ha classificato la correzione per RHEL come "deferred", cioè rimandata a un aggiornamento futuro. Secondo la stessa Red Hat, questo significa che la correzione non è garantita, e una data non c'è.

Cosa fare adesso

Non c'è motivo di farsi prendere dal panico. Nessun vendor, nessun CERT e nemmeno il team CVE del kernel segnalano sfruttamenti attivi, e al 29 ottobre 2026 la vulnerabilità non compare nel catalogo Known Exploited Vulnerabilities di CISA. Il rischio, però, non va nemmeno sottovalutato. Il primo passo è controllare la versione del kernel con uname -r e installare subito l'aggiornamento, se la tua distribuzione lo ha già pubblicato.

Se gestisci server Ubuntu o RHEL, sfrutta questa attesa per fare l'inventario. Individua le macchine con servizi TCP raggiungibili su IPv4 e prepara il rollout del nuovo kernel, così da installarlo appena sarà disponibile. Verifica anche che sysctl net.ipv4.tcp_migrate_req restituisca 0 e che non siano attivi programmi eBPF di migrazione reuseport: così escludi almeno la race secondaria. Per quella principale non c'è un'impostazione da cambiare. Serve il kernel corretto, e su due distribuzioni server ampiamente usate non è ancora arrivato.

Fonti: thehackernews.com, cyberkendra.com, rescana.com