johnhsb/linux-tcp-uaf-cve-2026-98432CVE-2026-98432 (Linux IPv4 TCP inet_opt UAF): script diagnostico in sola lettura, mitigazioni nftables/sysctl senza riavvio, rollout Ansible e guida alla risposta (EN/KO)
Un kit di risposta per CVE-2026-98432, un bug di sicurezza della memoria nel codice che il kernel Linux utilizza per stabilire le connessioni TCP. Contiene tre elementi:
iptables, installato di default, o nftables dove iptables è assente), file di impostazioni del kernel (sysctl) e playbook Ansible, tutti applicati senza riavvio. La modalità predefinita si limita a contare i pacchetti.Redatto al 2026-11-03. Ogni mitigazione qui presente è temporanea e non sostituisce la correzione del kernel. Pianifica separatamente l'aggiornamento del kernel e il riavvio (o un livepatch).
| README | Guida | Script diagnostico | |
|---|---|---|---|
| 🇺🇸 Inglese (predefinito) | README.md | cve-2026-98432-guide.en.md | check_cve_2026_98432.sh |
| 🇰🇷 한국어 | README.ko.md | cve-2026-98432-guide.ko.md | check_cve_2026_98432_ko.sh |
iptables, installato di default, e non richiede riavvio. Per sicurezza, inizia solo contando; passa allo scarto una volta confermato che nessun traffico legittimo è interessato.L'header IP di una richiesta di connessione TCP può — raramente — contenere campi aggiuntivi chiamati opzioni IPv4. Il kernel mantiene queste opzioni in memoria durante la fase di instaurazione della connessione. Al momento della pulizia, liberava quella memoria immediatamente, anche se un altro core della CPU poteva ancora leggerla.
Usare la memoria dopo che è stata liberata si chiama use-after-free (UAF). Se nel frattempo qualcos'altro è stato collocato in quella posizione, il kernel legge dati errati, il che può portare a:
| Voce | Dettaglio |
|---|---|
| Interessati | Linux 4.4 e successivi, precedenti alla versione corretta di ciascun ramo. IPv6 non è interessato |
| Gravità | CVSS 9.8 (Critica) secondo il Kernel CNA, Red Hat e Ubuntu. SUSE, Amazon e Oracle la valutano 8.1, perché vincere la corsa temporale tra le CPU è difficile |
| Causa principale | La memoria è stata liberata senza attendere il periodo di sicurezza del kernel (periodo di grazia RCU). Correzione upstream: commit e3f33b0a1d89 (kfree → kfree_rcu) |
| Versioni del kernel corrette | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 o successivi — per i kernel delle distribuzioni, verifica se la correzione è inclusa, non il numero di versione |
Sfruttamento: al 2026-11-03 non è presente nel CISA KEV (il catalogo delle vulnerabilità note per essere sfruttate), e non sono stati segnalati attacchi nel mondo reale. Molti repository GitHub dichiarano di essere "PoC"; nessuno è verificato — non eseguirli su reti di produzione.
Kernel corretti per distribuzione (versioni e fonti nella guida §2.2)
| Distribuzione | Stato |
|---|---|
| RHEL 8 / 9 / 10 | ✅ Kernel corretti rilasciati il 2026-11-01 (RHSA-2026:93414 / 93412 / 93413). I nodi OpenShift (RHCOS) non sono ancora corretti |
| Debian 12 / 13 | ✅ Corretti (DSA-6568-1, DLA-4841-1, DLA-4850-1) |
| Amazon Linux 2 / 2023 | ✅ Corretti. Le AMI ottimizzate per EKS/ECS, Fargate e Bottlerocket sono in fase di distribuzione |
| Rocky Linux (CIQ RLC Pro / LTS) | ✅ Ogni variante supportata da CIQ è corretta. Per Rocky community, consultare Rocky Errata |
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | ⏳ In corso ("work in progress" al 2026-11-03) |
| Ubuntu 16.04 / 18.04 / 20.04 | ⏳ Il supporto standard è terminato — correzioni previste solo per gli abbonati a Ubuntu Pro (ESM) |
| SUSE, Oracle Linux, AlmaLinux, … | Correzioni segnalate — consultare l'avviso di ciascun fornitore |
Lo script diagnostico in 4. Cosa fare ora fornisce il verdetto esatto. Come guida approssimativa:
Perché un attacco funzioni, ① il server deve avere almeno due core CPU (due core devono accedere alla stessa memoria nello stesso momento), e ② il pacchetto dell'attaccante deve raggiungere il server con le sue opzioni IPv4 intatte.
| # | Se il server è… | Rischio | Cosa fare |
|---|---|---|---|
| 1 | In una VPC interna o in un nodo Kubernetes, multi-core, con un listener MPTCP (anche nei container) | 🔴 Root remoto | Applicare subito la regola del firewall e il sysctl, e correggere i kernel dei nodi. Alcune reti Kubernetes (CNI basati su eBPF) aggirano il firewall dell'host, quindi la correzione viene prima |
| 2 | Su un IP pubblico o dietro un load balancer L4 (AWS NLB, …) con un listener MPTCP | 🔴 Root remoto | Applicare subito la regola del firewall e il sysctl |
| 3 | Multi-core con solo servizi TCP ordinari | 🟠 Crash remoto | Applicare la regola del firewall (il solo sysctl non basta) |
| 4 | CPU singola (una vCPU) | 🟡 Molto improbabile che riesca | Includere nel ciclo di patch regolare |
| 5 | Raggiungibile solo tramite un proxy L7 (AWS ALB, CloudFront, Cloudflare, …) con accesso interno controllato | 🟡 I pacchetti di attacco non arrivano mai | Correggere per difendersi da attaccanti interni |
⚠️ Non concludere "nessun listener MPTCP, quindi siamo al sicuro". Red Hat afferma che verificare la presenza di listener MPTCP è "informativo più che rassicurante". Senza MPTCP un crash è comunque possibile, e non si può escludere un altro metodo di sfruttamento che non richieda MPTCP. Inoltre, sui kernel della famiglia RHEL 8
ss -Mpotrebbe mostrare i listener MPTCP come TCP ordinario.