Deutsch

Mitigazione temporanea di CVE-2026-98432, variante iptables

Questo repository contiene tre script che verificano un host Linux per CVE-2026-98432 e, dove non è disponibile un kernel corretto, scartano i pacchetti TCP IPv4 che trasportano opzioni IP con una singola regola iptables. È la controparte iptables di typhoon1217/cve-2026-98432-mitigation, che fa lo stesso con nftables. È una mitigazione temporanea, non una correzione. Non è stata testata contro un exploit reale (non esiste un PoC pubblico) e nessun fornitore la approva. L'autore è un amministratore individuale, non un fornitore.

A chi è destinato

È destinato agli host che non possono ottenere un kernel corretto e non possono eseguire la variante nftables:

• Vecchie release Debian che non ricevono più aggiornamenti del kernel: Debian 9 (stretch, 4.9), Debian 10 (buster, 4.19), Debian 11 (bullseye, 5.10). Nessuna di esse è più elencata nel security tracker di Debian per questa CVE.
• Host Ubuntu LTS in attesa del kernel del fornitore. Per la 22.04 la correzione è annunciata per 5.15.0-203, per la 24.04 per 6.8.0-149. Finché quel kernel non viene avviato, la mitigazione colma la lacuna.
• Host con iptables ma senza nft, o con un nft troppo vecchio per ip hdrlength.
• Host in cui un unico metodo deve essere applicato uniformemente su sistemi vecchi e nuovi, così che apply, check e revert siano identici ovunque.

Non è destinato agli host Proxmox VE, che hanno un proprio kernel corretto (7.0.14-25-pve e successivi) e traffico bridged che richiede la regola bridge del repository nftables. Non è destinato agli host con SELinux o con etichettatura Smack NetLabel CIPSO, che possono raggiungere il codice vulnerabile senza opzioni IP. Non è destinato ai kernel precedenti alla 4.4, che non contengono il bug.

Se la tua distribuzione fornisce un kernel corretto, installalo, riavvia ed esegui cve-98432-revert-iptables.sh se hai applicato questa mitigazione.

Come funziona

CVE-2026-98432 è una race nella configurazione delle connessioni TCP IPv4. Il kernel conserva le opzioni IP di un SYN in ingresso in ireq_opt e, con il giusto tempismo, una CPU libera quell'oggetto mentre un'altra lo legge ancora. Nel codice mainline, ireq_opt viene impostato solo quando il SYN trasportava opzioni di intestazione IPv4, cioè quando l'intestazione IP è più lunga di 20 byte (IHL > 5), oppure tramite l'etichettatura CIPSO. Senza opzioni non c'è nulla da liberare o leggere. Pertanto la regola scarta ogni pacchetto TCP IPv4 la cui intestazione è più lunga di 20 byte:

iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

La corrispondenza u32 legge i primi quattro byte dell'intestazione IP, sposta il primo byte verso il basso e ne mantiene il nibble basso, che è il campo IHL in parole da 32 bit. 6:15 corrisponde a ogni valore superiore a 5. L'hook PREROUTING della tabella raw viene eseguito prima che il kernel analizzi le opzioni e prima di conntrack. Il traffico di loopback passa per lo stesso hook, ed è ciò su cui si basa l'autotest.

In un network namespace con un listener di loopback, un SYN semplice si è connesso e un SYN con l'opzione Record Route è andato in timeout, con il contatore della regola a 2 pacchetti (SYN e un retransmit). La regola nftables ip hdrlength gt 5 si è comportata in modo identico. Sono stati testati sia iptables-legacy che iptables-nft.

Il traffico TCP legittimo con opzioni IP è raro. Su nove host di produzione (mail, DNS, web, XMPP) il contatore è rimasto ai pacchetti dell'autotest per tutta la finestra di osservazione.

Se questo ti riguarda

1. Esegui cve-98432-check.sh. È in sola lettura. Guarda status, kernel_upstream_base e kernel_changelog_cve. I kernel dei vendor includono la correzione con i propri numeri di versione, quindi quando il changelog del kernel in esecuzione nomina la CVE, questo prevale sul confronto delle versioni.
2. Guarda iptables_u32_probe. Deve dire ok. La probe esegue iptables -C, che chiede solo se la regola esiste e quindi non aggiunge nulla; la risposta indica se la corrispondenza u32 e la tabella raw sono utilizzabili su questo kernel.
3. Guarda selftest_ipopt. CONNECTED significa che un SYN con opzioni IP attualmente passa. FAIL significa che è già scartato.
4. Requisiti: root, bash, iptables con xt_u32 e iptable_raw, systemd. Python 2 o 3 per l'autotest. Gli host senza systemd non sono coperti.

Testato su Debian 9 (iptables 1.6.0, legacy), Debian 10 e 11 (iptables 1.8.x, backend nf_tables) e Ubuntu 22.04 (iptables 1.8.7). Il percorso di avvio è stato testato su Debian 10.

Applicazione

Gli script vengono inviati all'host via SSH sullo standard input, quindi non occorre copiare nulla in anticipo.

1. Esegui il controllo sull'host pilota e leggi l'output:

   ssh root@HOST 'bash -s' < cve-98432-check.sh
   

2. Applicare sul pilota:

   ssh root@HOST 'bash -s' < cve-98432-apply-iptables.sh
   

   È idempotente. Installa /usr/local/sbin/cve-2026-98432-mitigation (start|stop|status), un'unità systemd oneshot cve-2026-98432-mitigation.service che carica la regola prima di network-pre.target e, solo quando il kernel conosce MPTCP, /etc/sysctl.d/99-cve-2026-98432.conf con net.mptcp.enabled = 0. Esce prima di modificare qualsiasi cosa se non è root, se iptables o systemd mancano, o se la sonda u32 fallisce.
3. Confronta le ultime righe con il riferimento:

   host=... svc=active enabled=enabled mptcp=n/a
   -A PREROUTING -p tcp -m u32 --u32 "0x0>>0x18&0xf=0x6:0xf" -j DROP
   selftest_plain=CONNECTED
   selftest_ipopt=FAIL TimeoutError
   

   mptcp=0 sui kernel 5.6 e successivi. Le versioni precedenti di Python stampano FAIL timeout, che è lo stesso risultato.
4. Riavviare il pilot e verificare che l'unità sia stata avviata prima della rete e che la regola sia presente:

   ssh root@HOST 'systemctl is-active cve-2026-98432-mitigation; /usr/local/sbin/cve-2026-98432-mitigation status'
   

5. Distribuisci a tutti gli altri:

   while read -r h; do echo "##### $h"; ssh root@$h 'bash -s' < cve-98432-apply-iptables.sh; done < hosts.txt
   

6. Se un servizio è in ascolto con MPTCP, riavvialo. Il sysctl influisce solo sui nuovi socket.

Verifica

Esegui nuovamente il controllo su ogni host mitigato e osserva due campi:

Campo	Atteso
cve_service	enabled/active
selftest_ipopt	FAIL ... (il SYN con opzioni IP è stato scartato)

Il self-test utilizza il loopback. Il traffico proveniente dalla rete passa attraverso lo stesso hook PREROUTING, quindi il risultato è valido anche in quel caso. Se vuoi confermarlo dall'esterno, check-blocked.py e verify-synack.sh del repository nftables funzionano senza modifiche su un host mitigato in questo modo.

Per monitorare i contatori:

while read -r h; do
  printf '%-28s ' "$h"
  ssh -n root@$h '/usr/local/sbin/cve-2026-98432-mitigation status' 2>&1 | awk '{print "pkts="$1, "bytes="$2}'
done < hosts.txt

Ogni self-test aggiunge 2 pacchetti. Un contatore che cresce oltre questo valore significa che traffico reale con opzioni IP raggiunge l'host; esaminare questo aspetto prima di decidere qualsiasi cosa. Il parametro -n è importante: senza di esso, ssh legge il resto dell'elenco degli host dallo standard input e il ciclo si interrompe dopo il primo host.

Se qualcosa si rompe

Il sintomo è una connessione TCP che si blocca (va in timeout) anziché essere rifiutata, insieme a un contatore in aumento.

Comando	Effetto
systemctl stop cve-2026-98432-mitigation	disattivato immediatamente, si riattiva al riavvio
systemctl disable --now cve-2026-98432-mitigation	disattivato ora e ai successivi riavvii