CVE-2026-98432: una patch annunciata non protegge ancora il server

Una patch annunciata non è necessariamente una patch che puoi installare oggi, e una patch installata non è necessariamente quella che sta proteggendo il server in questo momento. La vicenda di CVE-2026-98432, una vulnerabilità critica nel kernel Linux, mette in evidenza proprio questo spazio tra scoperta, correzione, distribuzione e riavvio. Uno spazio che in produzione si misura in giorni di esposizione, non in comunicati stampa.

Il problema tecnico, senza trasformare il CVSS in una profezia

La vulnerabilità interessa la gestione delle connessioni TCP IPv4 del kernel Linux. Nel percorso di creazione di una connessione, la proprietà delle opzioni IP può passare dal socket di richiesta a quello figlio mentre un’altra CPU sta ancora elaborando un SYN ritrasmesso. La combinazione può portare a un use-after-free: memoria già liberata viene letta da un percorso concorrente. La scheda tecnica di Canonical descrive il problema nelle funzioni coinvolte e assegna un CVSS 3.1 di 9,8.

Questo è un dato di gravità, non una dimostrazione che qualsiasi server Ubuntu sia compromettibile con la stessa procedura. Canonical precisa che l’exploit di ricerca descritto da Anthropic impiega Multipath TCP, ma la vulnerabilità non è limitata a MPTCP. Di conseguenza, disabilitare MPTCP non equivale a correggere il difetto: può modificare una condizione di uno specifico exploit, non eliminare il bug del kernel. L’indicazione del team di sicurezza Ubuntu è applicare gli aggiornamenti di sicurezza.

Upstream, -proposed e aggiornamento stabile sono tre stati diversi

Quando un fix entra nel codice upstream, la distribuzione deve ancora integrarlo nei propri rami, costruire i pacchetti e verificarne la compatibilità. Ubuntu usa il pocket -proposed per la fase di qualificazione. Un kernel disponibile lì può essere installato intenzionalmente da chi ha una procedura di acceptance test, ma non viene selezionato automaticamente dal normale aggiornamento dei sistemi.

Nel comunicato Canonical del 2 novembre 2026 i fix per Ubuntu 22.04 LTS, 24.04 LTS e 26.04 LTS sono indicati nel pocket -proposed, rispettivamente con riferimenti 5.15.0-203.213, 6.8.0-149.149 e 7.0.0-43.43. Canonical spiega che i test coinvolgono oltre duemila server e dispositivi certificati e che il rilascio nel pocket degli aggiornamenti ordinari avverrà dopo la qualificazione. È una scelta che prova a contenere le regressioni, ma che non deve essere confusa con l’avvenuta distribuzione della patch ai sistemi di produzione.

C’è anche un dettaglio che invita alla prudenza: il blog del 2 novembre elenca Ubuntu 26.10 come corretto, mentre il tracker CVE aggiornato al 5 novembre mostra ancora, per il pacchetto linux di 26.10, lo stato Vulnerable / work in progress. Le due pagine ufficiali non descrivono quindi lo stesso stato in modo coerente. Invece di scegliere la versione più rassicurante, chi amministra un sistema deve verificare l’advisory e il pacchetto applicabile al proprio kernel, alla propria release e al proprio repository al momento dell’intervento.

Il kernel installato non è sempre il kernel in esecuzione

Per un controllo iniziale servono almeno tre informazioni: la release Ubuntu, il kernel effettivamente avviato e le immagini kernel installate. Canonical suggerisce due comandi semplici:

uname -r
dpkg -l 'linux-image*' | grep ^ii

Il primo risponde alla domanda su cosa stia eseguendo la macchina; il secondo elenca i pacchetti presenti. Se un aggiornamento del kernel è stato installato ma non è seguito un riavvio, le due informazioni possono divergere. Il riavvio è esplicitamente richiesto nella procedura di Canonical per queste correzioni. Prima di programmare un intervento bisogna inoltre identificare il flavour realmente utilizzato: generic, HWE, cloud, KVM e altri rami non vanno trattati come se condividessero automaticamente lo stesso stato di patch.

Su una flotta di server la domanda utile non è soltanto “abbiamo lanciato apt upgrade?”, ma “quali host stanno ancora eseguendo un kernel vulnerabile, quali hanno una correzione qualificata disponibile e quali aspettano il reboot?”. Senza questa distinzione il report di aggiornamento può apparire verde mentre il rischio operativo rimane aperto.

Cosa fare in produzione mentre il fix attraversa la pipeline

Il percorso ragionevole parte dall’inventario, non da una modifica impulsiva dei repository. Identifica sistemi e servizi esposti, verifica il tracker del produttore e l’eventuale advisory specifico per il ramo kernel, confronta il pacchetto corretto con quello avviato e stabilisci una finestra di manutenzione compatibile con il servizio. Dove la patch è ancora soltanto in -proposed, la sua adozione richiede test e una valutazione esplicita del rischio di regressione: abilitare indiscriminatamente quel pocket su tutti i server non è una policy di sicurezza.

La stessa prudenza vale per le mitigazioni di rete. La pagina CVE di Ubuntu riporta anche una proposta di filtraggio delle opzioni IPv4, ma ne segnala i limiti e i possibili impatti sulle connessioni legittime. Non è una sostituzione universale dell’aggiornamento. Per un servizio esposto, eventuali controlli compensativi vanno testati e documentati come temporanei, senza presentare un filtro come soluzione definitiva.

Il vero indicatore è il tempo fino al kernel corretto in esecuzione

Le distribuzioni LTS hanno un compito difficile: distribuire rapidamente correzioni gravi senza introdurre regressioni su una quantità enorme di hardware e workload. Il punto non è negare quel trade-off. È smettere di misurare la sicurezza con una sola data: quella del commit upstream, quella dell’annuncio o quella dell’installazione del pacchetto.

Per chi gestisce infrastrutture, il risultato verificabile è un altro: il kernel corretto è disponibile per quel ramo, è stato installato, è stato avviato e i servizi sono tornati operativi dopo i controlli. CVE-2026-98432 è un promemoria molto concreto: tra “fix disponibile” e “server protetto” c’è un processo operativo. Se quel processo non è osservabile, nemmeno il suo esito lo è.