Linux, falla TCP CVE-2026-98432: kernel da installare e mitigazione con nftables

Articolo aggiornato al 7 novembre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Canonical e gli altri distributori rilasciano nuove correzioni.

Questa volta non c’è un sintomo da inseguire: i server funzionano, nessun servizio si ferma, i log sono puliti. Eppure in questi giorni stanno arrivando aggiornamenti urgenti del kernel per quasi tutte le distribuzioni Linux, e il motivo è una vulnerabilità nello stack TCP classificata con punteggio CVSS 9.8, la CVE-2026-98432.

Il problema è un use-after-free nella gestione delle opzioni IPv4 durante l’apertura di una connessione TCP. Un attaccante che raggiunge una qualunque porta TCP in ascolto su IPv4 può inviare un SYN con opzioni IP (Record Route o Timestamp) e poi ritrasmetterlo, fino a provocare la corruzione della memoria del kernel. Non servono credenziali né interazione dell’utente. È stato dimostrato un exploit che porta a ottenere root, al momento non pubblicato, e non risultano attacchi confermati. Non è un buon motivo per aspettare.

Chi è coinvolto

Il difetto è presente dal kernel 4.4, quindi da gennaio 2016: in pratica qualsiasi server, VPS o macchina virtuale Linux con un servizio TCP esposto su IPv4, da SSH al web server. Lo stack IPv6 non è coinvolto nel percorso principale, ma quasi tutti i server hanno anche IPv4 attivo.

Lo stato delle correzioni, al momento in cui scrivo:

• RHEL e AlmaLinux: kernel corretti disponibili, 4.18.0-553.182.1.el8_10 per la 8, 5.14.0-687.64.1.el9_8 per la 9 e 6.12.0-211.72.1.el10_2 per la 10;
• Debian 12: linux 6.1.190-1 (o linux-6.12 6.12.113-1~deb12u1); Debian 13: 6.12.113-1 o successivo;
• Ubuntu 22.04, 24.04 e 26.04: i kernel corretti sono in preparazione e non ancora pubblicati nel canale di sicurezza; Ubuntu 20.04 e precedenti risultano vulnerabili senza correzione annunciata;
• kernel upstream: corretti dalle versioni 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10.

Per Proxmox VE, NAS e appliance basate su Linux non ho ancora trovato indicazioni ufficiali: controllate le note di rilascio del produttore prima di dare per scontato che siano protetti. Per gli host Proxmox la procedura di aggiornamento del kernel è la stessa che ho descritto per la falla PwnEscape.

Prima di iniziare

• Fate uno snapshot della VM o verificate che l’ultimo backup sia andato a buon fine: un kernel nuovo che non si avvia è raro, ma succede.
• Assicuratevi di avere un accesso alla console (IPMI, iDRAC, console dell’hypervisor o del provider) per il caso in cui il server non torni raggiungibile dopo il riavvio.
• Partite dai server esposti su Internet, poi passate a quelli interni.

Aggiornare il kernel

Prima di tutto annotate il kernel in esecuzione:

uname -r
uname -v

Su RHEL, AlmaLinux e derivate:

sudo dnf upgrade --refresh 'kernel*'
rpm -q kernel

Su Debian:

sudo apt update
sudo apt full-upgrade
dpkg -l 'linux-image*' | grep ^ii

Poi riavviate. Attenzione: installare il pacchetto non basta, il server resta vulnerabile finché non si avvia con il kernel nuovo. Dopo il riavvio ricontrollate con uname -r (e su Debian con uname -v, che riporta la versione del pacchetto) che la versione corrisponda a quella corretta. Su RHEL e AlmaLinux potete cercare la correzione direttamente nel changelog del kernel in uso:

rpm -q --changelog kernel-core-$(uname -r) | grep -i 'CVE-2026-98432'

Se non potete aggiornare subito

È il caso di Ubuntu in questo momento, o di un server che non potete riavviare prima del fine settimana. La mitigazione proposta da AlmaLinux scarta, prima di qualunque altra elaborazione, i pacchetti TCP su IPv4 che contengono opzioni IP, cioè quelli con intestazione più lunga dei 20 byte standard:

sudo nft -f - <<'EOF'
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

La tabella è separata dalle vostre regole e convive con firewalld o con una configurazione nftables esistente. Con sudo nft list table ip cve_2026_98432 vedete il contatore dei pacchetti scartati; per rimuoverla, una volta installato il kernel corretto:

sudo nft delete table ip cve_2026_98432

Il traffico normale non usa le opzioni IP, quindi nella stragrande maggioranza dei casi non vi accorgerete di nulla. Attenzione però a tre limiti:

• la regola non sopravvive al riavvio: se dovete riavviare prima di avere il kernel corretto, ricaricatela o aggiungetela a /etc/nftables.conf;
• non protegge i container con uno stack di rete separato, e sulle macchine che instradano traffico (router, firewall Linux) filtra anche quello in transito;
• interrompe CIPSO/NetLabel, che però nelle PMI non ho mai visto in uso.

Verificate anche due parametri del kernel. Il percorso di attacco dimostrato sfrutta un listener MPTCP, mentre tcp_migrate_req apre una seconda strada al difetto:

sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -lnMp

Se nessun servizio usa MPTCP (l’ultimo comando non elenca listener), potete disattivarlo e azzerare tcp_migrate_req in modo persistente:

printf 'net.mptcp.enabled = 0\nnet.ipv4.tcp_migrate_req = 0\n' | sudo tee /etc/sysctl.d/99-cve-2026-98432.conf
sudo sysctl --system

Attenzione: disattivare MPTCP da solo non chiude la vulnerabilità, perché il difetto di base riguarda il TCP normale. Io lo considero un complemento alla regola nftables, non un’alternativa, e in ogni caso nessuna delle due sostituisce l’aggiornamento.

Se il problema persiste

• Dopo l’aggiornamento uname -r mostra ancora il kernel vecchio: controllate quale voce avvia GRUB (sudo grubby --default-kernel su RHEL e AlmaLinux) e che /boot non sia pieno.
• Usate kernel non standard (HWE su Ubuntu, kernel dei provider cloud, UEK su Oracle Linux): verificate lo stato di quel pacchetto specifico nel tracker di sicurezza della distribuzione, perché i tempi di rilascio sono diversi.
• Sistemi fuori supporto come Ubuntu 20.04 senza abbonamento esteso o CentOS 7: non riceveranno correzioni. Lasciate attiva la regola nftables, limitate le porte esposte con il firewall perimetrale e pianificate la migrazione.

Avete già aggiornato i vostri server o state aspettando i kernel di Ubuntu? Raccontate nei commenti come vi state organizzando e se avete trovato appliance o NAS ancora scoperti: possono essere utili ad altri.