Una falla nello stack TCP IPv4 del kernel Linux, tracciata come CVE-2026-98432, ha cambiato valutazione nel giro di poche settimane: da "moderata" a critica, con un punteggio CVSS di 9.8. È raggiungibile da remoto, senza autenticazione, e la parte di codice interessata è presente dal kernel 4.4, cioè da quasi un decennio. Al momento nessun fornitore o CERT segnala attacchi in corso, ma la finestra tra la correzione upstream e le patch effettivamente installate sui server è proprio il periodo in cui conviene agire.

Cosa è successo

Il difetto è un use-after-free, cioè la lettura di memoria già liberata, nel percorso con cui il kernel accetta le connessioni TCP in ingresso. Quando un server riceve una richiesta di connessione IPv4 con opzioni IP (per esempio Record Route o Timestamp), il socket creato per la nuova connessione eredita quelle opzioni dal socket di richiesta senza copiarle. Se il client ritrasmette la richiesta mentre un altro processore sta ancora usando le opzioni per rispondere, una delle due parti può liberare la memoria mentre l'altra la legge ancora. È una condizione di competizione, quindi difficile da vincere in modo affidabile: è la ragione per cui alcuni fornitori avevano inizialmente assegnato punteggi bassi (Red Hat 5.9, poi 8.1 nei dati dell'advisory), per poi portarsi a 9.8 con il bollettino RHSB-2026-016 del 30 ottobre. Il team CVE del kernel ha assegnato 9.8 il 24 ottobre. IPv6 non è interessato sul percorso principale.

La correzione upstream, intitolata in sostanza "liberare le opzioni IPv4 dopo un periodo di grazia RCU", è entrata nel ramo principale a settembre; il CVE è stato pubblicato il 15 ottobre. Esiste anche una race correlata nella migrazione dei socket di richiesta, collegata al parametro net.ipv4.tcp_migrate_req e alla migrazione BPF reuse-port.

Stato delle patch

Il quadro non è uniforme, ed è qui che i team operativi rischiano di sbagliare.

  • Red Hat ha rilasciato il 1° novembre i kernel corretti per RHEL 8.10 (RHSA-2026:93414), RHEL 9.8 (RHSA-2026:93412) e RHEL 10.2 (RHSA-2026:93413), oltre al kernel real-time di RHEL 8. Serve il riavvio. Restano indicati come ancora interessati il kernel real-time di RHEL 9, RHEL for NVIDIA e le immagini RHEL CoreOS su cui girano i nodi di OpenShift Container Platform 4.
  • Debian, Oracle UEK e Amazon Linux hanno già pubblicato correzioni; per Debian 12 e 13 le fonti citano i kernel 6.1.190-1 e 6.12.113-1.
  • Ubuntu 22.04, 24.04 e 26.04 risultano vulnerabili: i kernel corretti (5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43) erano in fase di test nel repository proposed, senza data di rilascio. Le versioni più vecchie richiedono Ubuntu Pro. Le ricostruzioni di RHEL, come Rocky e Alma, seguono di solito con qualche giorno di ritardo.

Le tabelle di stato cambiano rapidamente: prima di agire vanno riverificate sull'advisory della propria distribuzione.

Sfruttamento: cosa si sa e cosa no

Non risultano attacchi reali e la vulnerabilità non era nel catalogo CISA KEV al 30 ottobre. Il 27 ottobre Anthropic ha dichiarato che un modello interno non rilasciato ha prodotto un exploit di laboratorio contro un server con listener Multipath TCP (MPTCP): circa 48 minuti per ottenere un indirizzo del kernel e altri 5 per una shell root. Il codice non è pubblico, e i tempi riguardano una sola dimostrazione controllata, non un tasso medio di successo. Su GitHub è comparso codice che rileva la condizione di competizione senza eseguire codice. Red Hat indica come esito primario un crash o una corruzione di memoria, con possibile esecuzione di codice. Il dato da tenere a mente è un altro: l'asticella per costruire exploit di questo tipo si sta abbassando, e le race condition "difficili" restano difficili meno a lungo.

Una superficie da controllare è MPTCP, che alcuni runtime (per esempio Go dalla versione 1.24) possono abilitare per impostazione predefinita. Canonical sostiene però che disattivare MPTCP non basti.

Cosa significa per le aziende italiane

Il profilo più esposto non è il grande datacenter, che ha cicli di patch strutturati, ma l'infrastruttura "di mezzo": server web e applicativi su Linux esposti direttamente a Internet, appliance e virtual appliance basate su kernel non aggiornabili dall'utente, cluster Kubernetes e OpenShift dove il kernel appartiene al nodo e non all'immagine del container. Ricostruire un'immagine non risolve nulla: il kernel è dell'host. Molte PMI italiane ospitano siti e gestionali su VPS o hosting condiviso, dove il kernel lo gestisce il fornitore: in questi casi la domanda da fare al provider è se e quando ha applicato la correzione.

C'è poi un tema di conformità. Per i soggetti NIS2 la gestione e divulgazione delle vulnerabilità e la manutenzione dei sistemi rientrano tra le misure di sicurezza minime di cui rispondere, e un sistema critico raggiungibile da Internet con una falla da 9.8 nota da settimane è difficile da giustificare in un audit. Per chi tratta dati personali, un'eventuale compromissione che porti a esfiltrazione ricade negli obblighi di notifica al Garante entro 72 ore ai sensi dell'articolo 33 del GDPR. Anche per questo la priorità va data agli host esposti, non a quelli interni.

Infine una nota sulla valutazione del rischio: il fatto che i punteggi iniziali fossero bassi e siano stati rivisti al rialzo mostra i limiti dell'affidarsi al solo CVSS pubblicato il giorno uno. Conviene incrociare punteggio, esposizione reale e disponibilità di exploit, rivalutando quando le informazioni cambiano.

Cosa fare subito

  • Censire i sistemi Linux raggiungibili da Internet e quelli con listener MPTCP, e dare loro la priorità.
  • Verificare il kernel effettivamente in esecuzione con uname -r, non solo il pacchetto installato: senza riavvio la correzione non è attiva.
  • Applicare l'aggiornamento del kernel e riavviare secondo la finestra di manutenzione; su RHEL usare gli RHSA indicati sopra.
  • Dove la patch non è ancora disponibile (per esempio Ubuntu o nodi OpenShift), valutare la mitigazione proposta da Red Hat: una regola nftables che scarta i pacchetti TCP IPv4 in ingresso con intestazione IP maggiore di 5 parole. È una riduzione parziale del rischio, non una correzione; va testata, perché può bloccare traffico legittimo con opzioni IP, non copre il traffico tra container sullo stesso host e va rimossa dopo l'aggiornamento.
  • Chiedere per iscritto ai provider di hosting e cloud lo stato della correzione sui kernel che gestiscono per voi.
  • Monitorare i riavvii anomali e i crash del kernel sui server esposti: sono il segnale più probabile di tentativi di sfruttamento falliti.
  • Seguire gli aggiornamenti di Red Hat su OpenShift/CoreOS e di Canonical su Ubuntu, e rivalutare se la vulnerabilità entra nel catalogo CISA KEV.