CVE-2026-98432: vulnerabilità TCP nel kernel Linux — cos’è e cosa fare sul tuo VPS o server dedicato

Al 29 ottobre 2026, la vulnerabilità CVE-2026-98432 del kernel Linux è corretta nei rami stabili ufficiali e in Debian, ma Ubuntu, Red Hat, AlmaLinux, Rocky e SUSE 15 non hanno ancora pubblicato un kernel corretto. Al momento della pubblicazione non è noto alcun exploit pubblico. Se hai un VPS o un server dedicato Linux con Fusiora, il kernel lo gestisci tu: in questo articolo ti spieghiamo cosa è successo e quali passi seguire.

Cosa è successo, in parole semplici

Quando qualcuno apre una connessione TCP verso il tuo server, il kernel conserva temporaneamente alcune informazioni del primo pacchetto (il SYN). Se quel pacchetto contiene opzioni IPv4 (campi facoltativi dell’intestazione IP, come Record Route o Timestamp, che il traffico normale non usa quasi mai), il kernel può liberare quella memoria mentre un’altra parte del sistema la sta ancora usando. È ciò che si chiama use-after-free.

In pratica, l’esito più probabile è che il server vada in crash e si riavvii (denial of service). Le fonti ufficiali non concordano sulla gravità: la scheda del CVE parla anche di una possibile divulgazione all’attaccante di contenuti della memoria del kernel e di corruzione della memoria, mentre Red Hat indica che l’esito più probabile è un crash e che non è stato dimostrato alcun impatto su riservatezza o integrità.

Dettaglio tecnico in breve

• Correzione: commit e3f33b0a1d89 «ipv4: free inet_opt and ireq_opt after an RCU grace period» (Eric Dumazet, 1° ottobre 2026), incluso in Linux 7.3. Sostituisce due chiamate kfree() con kfree_rcu() in net/ipv4/af_inet.c e net/ipv4/tcp_ipv4.c.
• Causa: tcp_v4_syn_recv_sock() passa al socket figlio le opzioni IP della richiesta senza copiarle. Se nello stesso momento arriva un SYN ritrasmesso, un’altra CPU può star inviando un SYN-ACK con quelle opzioni mentre il socket figlio viene distrutto e le libera.
• Seconda variante: solo con la migrazione delle richieste TCP attiva (net.ipv4.tcp_migrate_req=1, che per impostazione predefinita vale 0, oppure un programma BPF reuseport che migra le richieste).
• Vettore: remoto e senza autenticazione, durante l’handshake, prima che intervenga l’applicazione. Servono un servizio TCP in ascolto su IPv4, un SYN con opzioni IP e vincere una race condition. Il CNA considera la complessità bassa; Red Hat e SUSE, alta.
• IPv6: non è interessato dalla falla principale. Non serve disattivare IPv6.

Chi è coinvolto?

• VPS Linux: ogni VPS avvia il proprio kernel, che installi e aggiorni tu dal sistema operativo. Se il tuo VPS usa un kernel vulnerabile, devi aggiornarlo e riavviare.
• Server dedicati Linux: lo stesso. Hai accesso root completo e il kernel è una tua responsabilità.
• Container (Docker, LXC, Podman) sul tuo server: condividono il kernel dell’host, quindi si proteggono aggiornando il kernel di quel server.
• Non coinvolti: Windows Server e FreeBSD, perché non usano il kernel Linux.

Stato delle patch al 29 ottobre 2026

Kernel ufficiali (kernel.org). Queste versioni, o qualsiasi versione successiva dello stesso ramo, includono già la correzione:

La scheda del CVE non elenca alcun ramo 4.x o 5.4 corretto (entrambi fuori dal supporto ufficiale).

Per distribuzione. Attenzione: ogni distribuzione numera i propri kernel a modo suo, quindi ciò che conta è il pacchetto corretto di ciascuna:

Nelle distribuzioni che distribuiscono kernel recenti dei rami ufficiali (per esempio Fedora, Arch o Alpine), confronta la tua versione con la tabella di kernel.org. Se usi Debian 10 o 11 o un altro sistema non più supportato, non contare di ricevere una patch: pianifica il passaggio a una versione supportata (su un VPS, dal pannello, Manage → Rebuild; attenzione, la reinstallazione cancella tutti i dati; su un server dedicato, apri un ticket). CentOS 7 usa il kernel di RHEL 7, che secondo Red Hat non è interessato da questo CVE, ma non riceve più aggiornamenti di sicurezza: conviene comunque migrare.

Passi per i clienti

Collegati via SSH (guida) ed esegui i comandi come root o con sudo.

1. Verifica quale kernel stai usando

uname -r

Su Debian, la versione esatta del pacchetto compare alla fine di:

uname -v

Per esempio, «Debian 6.12.113-1» o successiva su Debian 13 significa che hai già la versione corretta. Su Ubuntu, RHEL e derivate, il numero di uname -r è quello proprio della distribuzione: confrontalo con il suo avviso, non con la tabella di kernel.org.

2. Fai un backup prima di cambiare qualsiasi cosa

Se il tuo piano include gli snapshot, creane uno prima di aggiornare. Altrimenti, copia fuori dal server tutto ciò che non puoi permetterti di perdere. Aggiornare il kernel è un’operazione di routine, ma è al riavvio che può emergere un problema già esistente.

3. Aggiorna il sistema

Debian e Ubuntu:

apt update && apt full-upgrade

Su Debian 12, se usi il kernel 6.12 del pacchetto linux-6.12 (DLA-4850-1), full-upgrade aggiorna anche quello. Per verificare i pacchetti del kernel installati:

dpkg -l 'linux-image*'

AlmaLinux, Rocky, RHEL, Fedora, Oracle e CloudLinux:

dnf upgrade --refresh

rpm -q kernel

SUSE e openSUSE:

zypper refresh && zypper patch

Arch:

pacman -Syu

Alpine:

apk update && apk upgrade

Su Ubuntu, RHEL, AlmaLinux e Rocky al 29 ottobre non esiste ancora un kernel corretto; su Oracle Linux (kernel UEK) e CloudLinux, controlla l’avviso del tuo fornitore. Conviene comunque applicare gli aggiornamenti in sospeso, e dovrai ripetere questo passo non appena la tua distribuzione pubblicherà il suo avviso (vedi il passo 8); nel frattempo, applica la mitigazione del passo 5.

4. Riavvia e verifica la nuova versione

Il nuovo kernel non viene usato finché non riavvii:

reboot

Quando il server torna disponibile, esegui di nuovo uname -r (e uname -v su Debian) e confronta il risultato con il pacchetto corretto della tua distribuzione (tabella «Per distribuzione»), oppure con la tabella di kernel.org se usi un kernel ufficiale. Se dopo il riavvio il server non risponde via SSH:

• VPS: accedi al pannello vps.fusiora.com e apri la console VNC (scheda Options → Browser VNC; se non vedi il pulsante, fai prima clic su Enable VNC).
• Server dedicato: usa la console remota IPMI/KVM.
• Nel menu di GRUB (su Debian e Ubuntu, in «Advanced options»; se il menu non compare, tieni premuto Shift o premi Esc durante l’avvio) puoi scegliere il kernel precedente mentre indaghi.

5. Se la tua distribuzione non ha ancora la patch: mitigazione temporanea

La falla viene attivata solo da SYN TCP IPv4 che contengono opzioni IP, molto rari nel traffico legittimo. Puoi scartare questi pacchetti con nftables. La regola lascia passare i SYN normali e non tocca IPv6 né altri protocolli. Se il tuo server inoltra traffico (per esempio come router o gateway VPN), filtra anche quei SYN in transito. Non sostituisce la patch.

Se non hai il comando nft, installalo con apt install nftables o dnf install nftables. La regola risiede in una tabella propria, che convive con ufw, firewalld e Docker:

nft add table inet cve_2026_98432

nft add chain inet cve_2026_98432 pre '{ type filter hook prerouting priority -300; policy accept; }'

nft add rule inet cve_2026_98432 pre 'ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop'

Per verificarla (il contatore mostra quanti pacchetti ha scartato):

nft list table inet cve_2026_98432

Per rimuoverla:

nft delete table inet cve_2026_98432

Aggiunta in questo modo, la regola non sopravvive a un riavvio. Non aggiungerla a /etc/nftables.conf e non attivare nftables.service per questo: a seconda della distribuzione, quella configurazione svuota tutte le regole del sistema, comprese quelle di Docker o di ufw. Se ti serve che persista tra un riavvio e l’altro, salvala in un file a parte, /etc/cve-2026-98432.nft:

table inet cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop
  }
}

E caricala con un servizio dedicato, /etc/systemd/system/cve-2026-98432.service:

[Unit]
Description=Mitigation CVE-2026-98432

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table inet cve_2026_98432

[Install]
WantedBy=multi-user.target

Prima rimuovi la regola manuale, se l’hai aggiunta (nft delete table inet cve_2026_98432), così non viene duplicata. Poi:

systemctl daemon-reload && systemctl enable --now cve-2026-98432.service

Quando sarai sul kernel corretto, disattivala con systemctl disable --now cve-2026-98432.service.

Sui sistemi più vecchi senza nftables, l’equivalente con iptables è:

iptables -t raw -I PREROUTING -p tcp --syn -m u32 ! --u32 "0>>22&0x3C=20" -j DROP

Come la regola nft aggiunta a mano, anche questa non sopravvive a un riavvio.

Verifica inoltre che la variante legata alla migrazione sia disattivata (deve restituire 0, il valore predefinito):

sysctl net.ipv4.tcp_migrate_req

Se indica che la chiave non esiste, il tuo kernel non ha quella funzionalità e questa variante non si applica.

Non filtrare tutti i pacchetti con opzioni IP: IGMP le usa e romperesti il multicast. La regola qui sopra è volutamente limitata ai SYN TCP.

6. Livepatch: solo dove esiste

Al 29 ottobre 2026 non abbiamo trovato alcuna patch live per questo CVE da parte di Canonical, Red Hat o SUSE. SUSE ha pubblicato un kernel corretto per la 16.0 (6.12.0-160000.40.1), che richiede un riavvio. Senza patch live, la soluzione è aggiornare il kernel e riavviare.

7. Rivedi cosa esponi su Internet

La falla richiede un servizio TCP in ascolto su IPv4. È un buon momento per chiudere nel firewall (ufw o firewalld) le porte che non ti servono e limitare alle tue IP quelle di amministrazione. La nostra guida Configura il tuo primo VPS spiega la configurazione di base del firewall.

8. Segui gli avvisi e chiedi aiuto se ti serve

Segui la pagina del CVE della tua distribuzione (link qui sotto) e, quando compare il kernel corretto, ripeti i passi 3 e 4. Se hai domande o qualcosa non si avvia dopo l’aggiornamento, apri un ticket indicando il tuo servizio e l’output di uname -r.

Domande frequenti

Fusiora aggiorna il kernel del mio VPS o server dedicato?

No, a meno che tu non abbia sottoscritto un servizio gestito; in quel caso, rivolgiti al supporto. Con un VPS o un server dedicato standard hai accesso root completo e il sistema operativo lo gestisci tu, kernel incluso. Se vuoi aiuto con i passi, apri un ticket.

Basta aggiornare i pacchetti?

No. Finché non riavvii continui a usare il vecchio kernel. Controlla con uname -r di essere sulla nuova versione.

Devo disattivare IPv6?

No. IPv6 non è interessato dalla falla principale.

La regola nftables può rompere qualcosa?

Scarta solo i SYN TCP IPv4 con opzioni IP, molto rari nel traffico legittimo. Non tocca IPv6 né altri protocolli, e si rimuove con un solo comando.

Il mio Windows Server è coinvolto?

No. È una vulnerabilità del kernel Linux.

Viene già sfruttata?

Al momento della pubblicazione non è noto alcun exploit pubblico e il CVE non figura nel catalogo KEV della CISA. Aggiorneremo questo articolo se la situazione cambia.

---

Fonti

• CVE.org: scheda ufficiale del CNA Linux, pubblicata il 2026-10-15 e aggiornata il 2026-10-24
• NVD: voce del CVE con il punteggio del CNA (consultata il 2026-10-29)
• Ubuntu: stato per release, priorità High (aggiornata il 2026-10-28)
• Debian Security Tracker: pacchetti corretti, DSA-6568-1, DLA-4841-1 e DLA-4850-1 (consultato il 2026-10-29)
• Red Hat: valutazione Moderate e stato «Fix deferred» (consultata il 2026-10-29)
• SUSE: stato per prodotto (consultata il 2026-10-29)
• Commit della correzione Linux: «ipv4: free inet_opt and ireq_opt after an RCU grace period» (2026-10-01)
• kernel.org: versioni stabili attuali (consultato il 2026-10-29)
• CISA KEV: catalogo delle vulnerabilità sfruttate, senza questo CVE (consultato il 2026-10-29)