Mitigazione nft per CVE-2026-98432

Skill per agenti che applica, verifica, rende persistente e successivamente rimuove la mitigazione temporanea dell'host per la CVE-2026-98432 del kernel Linux (CVSS 9.8): una singola regola nftables che scarta i pacchetti TCP contenenti opzioni IPv4 — l'unico input che raggiunge la use-after-free di inet_opt/ireq_opt in tcp_v4_syn_recv_sock().

Contesto utile da conoscere: il Frontier Red Team di Anthropic ha descritto pubblicamente un PoC funzionante da non autenticato a root contro server che espongono un listener MPTCP (ottobre 2026); nessuno sfruttamento in the wild segnalato. Il CNA del kernel assegna 9.8; upstream e Red Hat assegnano 8.1 (complessità di attacco alta). La correzione del fornitore consiste nei backport della classe del kernel Ubuntu 6.8.0-149 — finché il kernel in esecuzione non include la correzione, questa regola è il tampone. È circoscritta a un campo di un header di un protocollo, quindi il traffico normale non viene toccato.

Questa regola non è nuova — trattala come prior art confezionata. Vedi "Prior art" di seguito; il contributo di questo repo è la forma riproducibile di agent-skill più le insidie di produzione.

Contenuti

Percorso	Cosa
`SKILL.md`	La skill — trigger nel frontmatter, ruleset, controlli, persistenza, insidie, rimozione
`files/cve98432.nft`	Ruleset nftables pronto all'uso (prerouting, priorità −300)
`files/nft-cve98432.service`	Unità systemd pronta all'uso (persistenza)

Installazione (agent skill)

cp -R cve-2026-98432-nft-mitigation ~/.claude/skills/     # Claude Code
cp -R cve-2026-98432-nft-mitigation ~/.agents/skills/     # agents-style runtimes

Il frontmatter description è la superficie di discovery: gli agenti selezionano questa skill quando viene chiesto di mitigare CVE-2026-98432, il "TCP/IP fix", la UAF delle opzioni IPv4 del kernel, o di rimuovere la mitigazione dopo che il kernel del fornitore è stato rilasciato.

Prima di applicare — tre controlli

Il kernel in esecuzione è già corretto? I backport modificano i numeri di versione — controlla il changelog del kernel che stai effettivamente eseguendo:
```
zgrep -c CVE-2026-98432 /usr/share/doc/linux-modules-$(uname -r)/changelog.Debian.gz   # Debian/Ubuntu
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432                     # RHEL/Rocky/Alma
```
> 0 = corretto, salta la mitigazione. (Controlla anche il tuo vendor tracker; e apt-cache policy linux-image-generic per un kernel più recente installato ma non avviato.)
Listener MPTCP (ss -lnMp): il PoC pubblicato li prende di mira, e Go ≥ 1.24 ascolta con MPTCP per impostazione predefinita sui kernel che lo consentono. sysctl net.mptcp.enabled=0 influisce solo sui nuovi socket — i listener già aperti mantengono MPTCP finché il loro servizio non viene riavviato (GODEBUG=multipathtcp=0 secondo il team Go).
Reti etichettate CIPSO: se cat /sys/kernel/security/lsm elenca SELinux o Smack e usi la mappatura NetLabel CIPSOV4, le opzioni IPv4 sono legittime lì — questa regola interromperebbe quel percorso. Non applicare su reti etichettate CIPSO (RFC 7126 discute il compromesso).

Utilizzo (richiede root)

Installa files/cve98432.nft e files/nft-cve98432.service.
nft -c -f /usr/local/sbin/cve98432.nft — controllo di parsing; richiede root (senza root fallisce a livello netlink: cache initialization failed).
systemctl daemon-reload && systemctl enable --now nft-cve98432.service
Riavvia l'unità due volte — prova di idempotenza. La riga destroy table … deve essere la prima riga del file: aggiunta alla fine crea la tabella e poi la distrugge, lasciando un ruleset vuoto mentre il servizio esce comunque con 0.
nft list table inet cve98432 deve mostrare meta l4proto tcp ip hdrlength > 5 counter drop su una chain con priority -300 (prima di conntrack, in linea con la regola pubblicata).
Coesistenza: una table inet … personalizzata non è gestita da iptables, quindi gli strumenti iptables-restore / ufw / firewalld la lasciano intatta (esegui il tuo restore una volta e rielenca per confermare).

Rimozione dopo che il kernel corretto è installato e riavviato: sezione 7 di SKILL.md.

Container: la regola deve risiedere anche nel loro netns

Lo stato di nftables è per network namespace. Le regole dell'host vedono il traffico di un container solo dove attraversa l'host (es. container → esterno); il traffico che rimane all'interno del namespace del container stesso (container → il proprio loopback/IP) non attraversa mai il prerouting dell'host — eppure il kernel è condiviso, quindi il codice all'interno di un container può comunque raggiungere la UAF localmente. Inietta lo stesso ruleset in ogni container in esecuzione:

# Docker (host-side nsenter keeps the needed capabilities)
for c in $(docker ps -q); do
  pid=$(docker inspect -f '{{.State.Pid}}' "$c")
  nsenter -t "$pid" -n /usr/sbin/nft -f /usr/local/sbin/cve98432.nft
done
# LXC (privileged CLI as root)
for c in $(lxc-ls -1 2>/dev/null); do lxc-attach -n "$c" -- nft -f /usr/local/sbin/cve98432.nft; done

I namespace dei container non mantengono le regole nft — rieseguire a ogni riavvio del container (agganciarlo al passo post-avvio del vostro orchestratore). Lavoro precedente per questa esatta lacuna, con script: typhoon1217/cve-2026-98432-mitigation (inject-netns.sh).

Verifica del drop (lato client)

Sono sufficienti socket standard — nessuna costruzione di pacchetti sul server: un client imposta un'opzione IPv4 Record Route tramite setsockopt(IP_OPTIONS) e si connette; una connessione semplice riesce, la connessione con opzioni deve andare in timeout mentre il contatore della regola si incrementa. Client pronti all'uso: check-blocked.py / verify-synack.sh in typhoon1217/cve-2026-98432-mitigation. Avvertenza da quel progetto: un client che esegue esso stesso la mitigazione scarterà anche gli echi SYN-ACK del target — testare da un client non mitigato per un verdetto pulito.

Perché questa regola

La UAF è raggiungibile solo tramite segmenti TCP il cui header IPv4 trasporta opzioni (IHL > 5); RFC 7126 raccomanda già che router/firewall scartino le opzioni Record Route/Timestamp, quindi questo non rompe nulla di reale.
prerouting a priority -300: prima di conntrack, così i pacchetti scartati non creano mai stato conntrack — e, a differenza di input, copre anche il traffico inoltrato a container/VM che attraversa l'host.
La semantica di match è auto-verificante: nft normalizza un @nh,4,4 > 5 grezzo in ip hdrlength > 5 — il campo IHL, confermato dallo strumento stesso.

Lavoro precedente (da leggere)

RFC 7126 — filtering IPv4 packets containing IPv4 options
typhoon1217/cve-2026-98432-mitigation — stessa regola di drop + iniezione container-netns, avvertenza CIPSO, client di verifica (EN/KO)
blog getrff.com (29 ottobre 2026) — stessa regola a priority −300, controlli MPTCP, scripting su flotta
writeup Atlas su CVE-2026-98432 — opzioni di trigger + regola
CIQ KB — "Mitigating CVE-2026-98432 on Rocky Linux" (procedura verificata per la regola firewall)
Red Hat RHSB-2026-016, Ubuntu CVE tracker, NVD

Provenienza

Estratto da un deployment in produzione, inclusi i fallimenti riscontrati lì: nft -c senza root, il bug di ordinamento del destroy alla fine, un heredoc senza quoting che mangiava silenziosamente \$, e la semantica di doppia applicazione. Repository di sola documentazione — dipendenze runtime: nft ≥ 1.0 + systemd; nessuna suite di test (n/a).

Più Popolari

cve-2026-98432-nft-mitigation