한국어

Mitigazione temporanea di CVE-2026-98432

Questo repository contiene script che scartano i pacchetti TCP IPv4 che trasportano opzioni IP su un host Linux. Su host privi di etichettatura CIPSO SELinux/Smack NetLabel, CVE-2026-98432 (un use-after-free nel TCP IPv4 del kernel Linux) non può essere attivato senza tali pacchetti. Si tratta di una mitigazione temporanea, non di una correzione. Non è stata testata contro un exploit reale (non esiste un PoC pubblico) e nessun fornitore la approva. Se la tua distribuzione fornisce già un kernel corretto, installalo, ed esegui revert.sh se hai applicato questa mitigazione. In caso contrario, verifica che la mitigazione sia applicabile al tuo host, quindi applicala e verificala con i passaggi seguenti (circa 10 minuti). L'autore è un amministratore individuale, non un fornitore.

Se questo si applica al tuo caso

1. Confronta uname -r con le versioni stabili corrette: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 (commit di correzione e3f33b0a1d89d738e2b913dab519226eaf76e15b). Un kernel di distribuzione può includere la correzione con un numero di versione diverso, quindi controlla anche il tracker del tuo fornitore.
2. Verifica la presenza dell'etichettatura CIPSO: cat /sys/kernel/security/lsm. Se SELinux o Smack sono elencati e utilizzi NetLabel con una mappatura CIPSOV4, questa mitigazione non copre quel percorso.
3. Verifica i requisiti: root, systemd e nft. OpenWrt ha un proprio percorso (vedi File). Gli host senza systemd, diversi da OpenWrt, non sono coperti.

Gravità: il CNA del kernel assegna CVSS 9.8. Red Hat, Oracle e SUSE assegnano 8.1, e Amazon assegna 7.0. Anthropic ha descritto pubblicamente un exploit remoto per root contro server Linux con un listener MPTCP (2026-10-27). Al 2026-10-29 non è stato segnalato alcun sfruttamento attivo.

Stato delle distribuzioni al 2026-10-29/30 (un'istantanea, quindi verifica presso il tuo fornitore):

Distribuzione	Stato
Ubuntu (tutte le release supportate)	nessun kernel corretto
RHEL 8/9/10	nessun kernel corretto
Proxmox VE	il changelog di pve-kernel non aveva alcuna voce per questa CVE il 2026-10-30
Debian, Oracle Linux UEK, alcune SUSE, alcune Amazon Linux	correzioni disponibili

Applicazione

1. Esegui sudo ./mitigate.sh. È idempotente (rieseguirlo ricarica il ruleset). Installa i file elencati in File, ed esce se non sei root, se nft è assente o se systemd è assente.

2. Confronta l'output con il riferimento seguente. La prima riga deve essere:

   svc=active enabled=enabled mptcp=0
   

   Le due regole lo seguono, una nella tabella inet e una nella tabella bridge.

3. Se un servizio è in ascolto con MPTCP, riavvialo. net.mptcp.enabled=0 influisce solo sui nuovi socket, quindi un listener MPTCP già aperto resta MPTCP finché il suo servizio non viene riavviato. Il sysctl è per network namespace, e mitigate.sh lo imposta solo per il namespace dell'host.

4. Se l'host esegue container LXC o Docker, continua con Containers.

L'exploit pubblicato prendeva di mira i listener MPTCP. La race in sé non richiede MPTCP (inferenza dalla descrizione della correzione). Non è stabilito se un host senza MPTCP possa essere completamente compromesso.

Verify

Il SYN-ACK del target restituisce le opzioni IP. Un client che esegue a sua volta questa mitigazione scarta quel SYN-ACK, quindi check-blocked.py riporta "blocked" anche quando il target non è mitigato. Misurato su un host: dopo revert.sh sul target, check-blocked.py da un client mitigato stampava comunque ipopt FAIL TimeoutError, mentre verify-synack.sh mostrava ipopt synack=5.

Scegli uno strumento:

1. Se disponi di un client senza questa mitigazione, esegui lì python3 check-blocked.py <host> <port> (non serve root). Si connette due volte: in chiaro, poi con un'opzione IPv4 Record Route impostata tramite l'opzione socket IP_OPTIONS.
2. Se non puoi garantirlo, esegui sudo ./verify-synack.sh <ip> <port> su qualsiasi client (servono root, tcpdump e python3 sul client). Invia un SYN in chiaro e un SYN con opzioni IP da porte sorgente fisse e conta i SYN-ACK del target con tcpdump.

Poi confronta l'output con la tabella per quello strumento.

check-blocked.py (da un client senza la mitigazione):

Output	Significato
plain CONNECTED	il TCP normale funziona
ipopt FAIL TimeoutError	il SYN con opzioni IP è stato scartato, come previsto

verify-synack.sh:

Output	Significato
plain: CONNECTED synack=N | ipopt: TimeoutError synack=0	il target è mitigato
ipopt ... synack>=1	il target non è mitigato (il SYN con opzioni IP ha ricevuto risposta)

Risultato a livello di kernel (un host Proxmox VE, kernel 7.0, 2026-10-30): con la mitigazione disattivata, il percorso di codice vulnerabile veniva eseguito una volta per path, su WireGuard e da LXC a LXC. Con la mitigazione attiva, il SYN andava in timeout e il path veniva eseguito 0 volte. Il campione è di 2 path in 2 stati su un host. Il metodo di tracing è in docs/ANALYSIS.md (in inglese).

Containers

Lo stato di nftables è per network namespace, quindi le regole dell'host da sole non proteggono i namespace dei container. Misurato su container LXC: con sole regole sull'host, un SYN con opzioni IP dall'interno di un container verso il proprio 127.0.0.1 o il proprio IP si connetteva. I container condividono il kernel dell'host, quindi il codice all'interno di qualsiasi container poteva raggiungere in questo modo il percorso vulnerabile.

1. Completa prima Apply sull'host.
2. Esegui sudo ./inject-netns.sh sull'host. Carica lo stesso ruleset in ogni container LXC in esecuzione (tramite pct/lxc-info, Proxmox) e in ogni container Docker in esecuzione (i container in modalità host-network vengono saltati).
3. Confronta l'output con la tabella.

Output	Significato
ok lxc:<id> o ok docker:<id>	ruleset caricato in quel namespace del container
injected=N failed=M	totali, M dovrebbe essere 0

L'iniezione non è persistente. Va persa quando un container viene riavviato, quindi riesegui lo script dopo i riavvii. I container Docker annidati all'interno di un container LXC richiedono l'esecuzione dello script all'interno di quel container LXC (non misurato).

Risultato misurato: su 5 host Proxmox, 64 namespace di container sono stati iniettati con 0 errori. Dopo l'iniezione, lo stesso test andava in timeout e il contatore di drop del namespace del container aumentava.

If something breaks

Il sintomo di un'interferenza di questa mitigazione è una connessione TCP che si blocca (va in timeout) anziché essere rifiutata, insieme a un contatore in aumento nell'output di:

nft list ruleset | grep counter

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

Compatibilità misurata sugli host testati: le regole risiedono in tabelle proprie e hanno coesistito con Docker, ufw, regole NAT di iptables-legacy e routing NetBird (WireGuard). Le normali connessioni TCP hanno continuato a funzionare su ogni percorso testato. I contatori di drop sono rimasti ai valori dei pacchetti di test durante il normale funzionamento (nessun traffico legittimo corrispondeva) in una breve finestra di osservazione (ore, non giorni).

Inferenza, non misurata: un nftables.service la cui configurazione contiene flush ruleset eliminerebbe le tabelle al momento del reload. Verificare questa eventualità e rieseguire mitigate.sh dopo tale reload.

Rimozione dopo la patch