Linux TCP use-after-free: patch o mitigazione?

Il tuo kernel ha una use-after-free raggiungibile da remoto nel percorso dell'handshake TCP, la tua distribuzione non ha ancora rilasciato una fix e qualcuno ha già dimostrato un exploit funzionante per ottenere root. Quindi qual è il piano: aspettare con le mani in mano o iniziare a scartare pacchetti al firewall? La use-after-free TCP di Linux segnalata come CVE-2026-98432 è un caso di studio pulito sulla decisione più vecchia della sicurezza operativa, cioè patch contro mitigazione, e la risposta onesta è che le due opzioni non sono affatto simmetriche. Una delle due risolve davvero il problema.

Ho vissuto entrambi i lati di questa decisione. Ho rimandato un rollout d'emergenza del kernel perché la mitigazione sembrava sufficiente sulla carta, e ho anche visto una regola firewall « temporanea » marcire in silenzio in produzione per otto mesi, mentre tutti dimenticavano il CVE che stava coprendo. Questo bug è un buon punto di partenza per ragionare su quando vince ciascun approccio, perché i compromessi qui sono insolitamente chiari.

Cos'è davvero la use-after-free TCP

I meccanismi contano, perché determinano cosa una mitigazione può e non può fare. Quando il server accetta una connessione TCP su IPv4, il kernel tiene traccia dell'handshake semi-aperto in una request socket leggera, poi la promuove a socket completo una volta terminato l'handshake. Se l'header IPv4 del peer contiene delle opzioni, il kernel le salva per riproporle nelle risposte. Il bug: il kernel passava quelle opzioni salvate alla nuova connessione senza copiarle, poi le liberava subito, mentre un'altra CPU poteva ancora leggerle per costruire la risposta dell'handshake. È una use-after-free, raggiungibile da un peer remoto non autenticato, prima ancora che venga eseguita una sola riga del tuo codice applicativo.

La fix upstream, di Eric Dumazet, è di quattro righe: due chiamate semplici a kfree() diventano kfree_rcu(), che rimanda la liberazione finché ogni lettore non ha finito di usare la memoria. È la fix canonica del kernel per questa classe di bug: i lettori sotto RCU detengono riferimenti che non vedi, quindi lasci scadere il grace period prima di recuperare la memoria. Il CNA del kernel le ha assegnato un CVSS di 9.8. Red Hat inizialmente aveva dato 8.1, poi ha alzato il punteggio a 9.8 Critical il 30 ottobre, citando l'assenza di prerequisiti di rete.

Due dettagli cambiano il calcolo dell'esposizione. Primo, la race fallisce in modo indolore: un tentativo fallito fa solo cadere l'handshake senza mandare in panic la macchina, quindi un attaccante può riprovare all'infinito. Secondo, il percorso di exploit dimostrato da Anthropic colpisce host con un listener TCP multipath, e secondo il Go Security Team i programmi Go aprono listener MPTCP di default su Linux dalla versione 1.24, ovunque il kernel lo consenta. Controlla la tua flotta:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Un output vuoto di ss -M significa che non ci sono listener MPTCP. Ma non rilassarti: il team Go è esplicito nel dire che il bug di fondo non è specifico di MPTCP. È una UAF generica nella gestione dell'handshake; MPTCP è solo il percorso che qualcuno ha dimostrato end-to-end.

Il percorso della patch: kernel corretto, riavvio, fatto

La patch è noiosa da descrivere perché è l'unica opzione che elimina la vulnerabilità invece di spostarla. I kernel corretti sono usciti upstream l'11 e il 15 ottobre su tutte le linee stabili mantenute, e il bug risale a Linux 4.4, quindi molti sistemi in coda lunga sono colpiti, inclusi kernel così vecchi che upstream non li tocca più.

Il problema è il riavvio. Un aggiornamento del kernel non fa nulla finché la macchina non parte con quello nuovo, e il costo operativo reale sta proprio lì: nodi Kubernetes svuotati, prove di failover, il primary del database che nessuno vuole riavviare in orario di lavoro. Per questo « basta applicare la patch » è sempre corretto come consiglio e mai sufficiente. Ti serve un piano di rollout: prima gli host canary, poi i livelli stateless, infine quelli stateful con finestre di manutenzione. Se hai già affrontato una rotazione d'emergenza del kernel su tutta la flotta, sai già come funziona. I team che gestiscono bene questi casi sono quelli che hanno provato il drain dei nodi quando nessuno era in allarme; le buone abitudini di ingegneria difensiva che costruisci nelle giornate tranquille sono quelle che ti salvano durante un 9.8.

Una trappola da segnalare: vedere un pacchetto corretto con dpkg -l o rpm -q kernel non significa nulla se il kernel in esecuzione è precedente. uname -r ti dice cosa sta davvero girando. Sulle distribuzioni basate su RHEL, needs-restarting -r ti dice chiaramente se un riavvio è in sospeso. Ho letto report post-incidente in cui la flotta « patchata » era in realtà una flotta di kernel installati ma non in esecuzione. Verifica la versione in esecuzione sul tracker della tua distribuzione, non sul numero upstream: i kernel delle distribuzioni portano backport sotto il loro sistema di versioni.

Il percorso della mitigazione: scartare le opzioni IPv4, disabilitare MPTCP

La mitigazione provvisoria pubblicata è una regola nftables che scarta i pacchetti TCP IPv4 in ingresso con opzioni IP, cioè la condizione di attivazione del percorso vulnerabile. Puoi affiancarla disabilitando MPTCP (sysctl -w net.mptcp.enabled=0) se non lo usi. Entrambe sono rapide, non richiedono riavvii e si possono distribuire con il tuo strumento di configuration management in un pomeriggio. È questo il loro fascino.

Ora la parte che dovrebbe frenare l'entusiasmo: il bollettino di Red Hat dice che la loro regola « riduce l'esposizione a questa vulnerabilità ma non può prevenirla del tutto ». Leggi quella frase due volte. La mitigazione restringe la superficie d'attacco, ma non la chiude. I pacchetti con opzioni IP sono rari nel traffico normale, e la maggior parte dei middlebox li scarta comunque, ed è uno dei motivi per cui lo sfruttamento su internet aperto è considerato poco probabile. Però « raro » e « impossibile » non sono la stessa cosa, e il bug sta nel codice generico dell'handshake, non solo nel percorso delle opzioni che qualcuno ha testato.

C'è anche un costo più sottile: le mitigazioni creano un falso senso di chiusura. Il ticket passa a « quasi fatto », l'urgenza si disperde nel lavoro di patching e sei settimane dopo stai ancora girando un kernel vulnerabile dietro un packet filter, con una memoria istituzionale che svanisce rapidamente sul perché. Ho già scritto di questo schema parlando della finestra dei CVE critici di PHP, dove i team che hanno semplicemente tolto offline il componente vulnerabile se la sono cavata meglio di quelli che hanno impilato filtri astuti. Stessa lezione, stack diverso.

Patch o mitigazione: quando vince ciascuna

Ecco il mio punteggio onesto, dopo anni a prendere questa decisione sotto pressione.

• Il kernel corretto è disponibile per la tua distribuzione. Vince la patch, senza discussioni. Debian, SUSE Enterprise, Oracle UEK e Amazon Linux hanno rilasciato tutti le fix. Non esiste mitigazione più intelligente di una fix upstream di quattro righe. Pianifica i riavvii, procedi a ondate e vai avanti.
• Nessun kernel corretto ancora, l'esposizione è reale. Mitiga subito: è esattamente a cosa servono le mitigazioni. Ubuntu e RHEL risultavano ancora « Vulnerable »/« affected » alla fine di ottobre. Se sei esposto su internet con un listener MPTCP, scarta i pacchetti con opzioni IP e disabilita MPTCP oggi stesso, mentre tieni d'occhio il kernel corretto come una release che stai bloccando.
• Esposto su internet ma dietro un front door gestito. L'urgenza scende. Le indicazioni di AWS, secondo cui il traffico filtrato dai loro load balancer, da CloudFront o da API Gateway non raggiunge le istanze come TCP grezzo e non attendibile, sono sensate. Mitiga comunque (costa poco) e applica la patch nel ciclo normale invece che in quello d'emergenza.
• Sistemi single-core o con una sola coda. Priorità più bassa. La race richiede elaborazione concorrente dei pacchetti su più CPU. Embedded e VM piccole hanno un po' di respiro, ma sono anche le macchine che nessuno riavvia mai, quindi non lasciare che « bassa priorità » diventi « mai ».
• Kernel end-of-life (upstream precedenti alla 5.10). La mitigazione è l'unica opzione indipendente dall'upstream. Questo è lo scenario in cui le mitigazioni vincono davvero, perché l'alternativa è un backport del vendor che potrebbe non arrivare mai. È anche un segnale forte che la macchina stessa è la vulnerabilità, e che la vera soluzione è sostituirla.

Il vero problema è il divario delle distribuzioni

Il dettaglio che dovrebbe preoccuparti non è il bug: le fix da quattro righe per le UAF arrivano nei kernel stabili ogni mese. È che due delle più grandi distribuzioni server al mondo, Ubuntu e RHEL, erano ancora senza fix rilasciate più di due settimane dopo l'upstream, mentre Amazon Linux aveva patchato tutti i suoi kernel e AlmaLinux, una ricostruzione comunitaria, aveva fix per i kernel in test prima dello stesso upstream. La community di Hacker News se n'è accorta ed è giustamente irritata: sono le distribuzioni che si vendono di più come pronte per i server.

Per chi lavora sul campo la conclusione è poco appariscente: la tua finestra di esposizione dipende dalla pipeline di backport del vendor, non dall'upstream. Questo porta a due cose. Primo, conosci gli URL dei tracker della tua distribuzione e tienili davvero sotto controllo: questo CVE è rimasto in stato « Received » su NVD senza analisi, mentre il CNA del kernel, Red Hat e le distribuzioni avevano già pagine dettagliate. Secondo, considera la reattività della distribuzione come criterio di scelta. Amazon Linux ha appena dimostrato una pipeline di fix per il kernel sensibilmente più veloce dei due concorrenti storici. Questo non conta in una presentazione commerciale, ma conta nel weekend di Halloween, quando esce un 9.8.

L'exploit scritto con l'AI cambia l'orologio

La riga più importante della segnalazione è facile da scorrere: Anthropic riferisce che il suo modello Claude ha prodotto un exploit remote-root funzionante, dopo un prompt iniziale, impiegando meno di un'ora di tempo macchina per andare dal leak di un puntatore del kernel a una root shell. Non l'hanno pubblicato, e gli scettici su HN si sono divertiti con il tono « fidatevi di me, bro ». Giusto. Ma anche scontando il marketing, la direzione è inequivocabile: il tempo tra « la diff arriva nell'albero stabile » e « esiste un exploit funzionante » si sta riducendo, perché il collo di bottiglia dell'exploit non è mai stato il bug, ma l'essere umano capace di leggere la diff e fare l'heap grooming.

Questo comprime la finestra della decisione tra patch e mitigazione. Quando sviluppare un exploit richiedeva settimane, « mitiga ora, applica la patch nella prossima finestra di manutenzione » era difendibile. Quando un modello può sfornare un PoC in una notte partendo da un commit pubblico, la fase di mitigazione va misurata in ore e quella di patching in giorni. La fix da quattro righe è pubblica. Chiunque può studiarla. Dai per scontato che l'exploit sia altrettanto accessibile.

La mia raccomandazione

Applica la patch. Usa la mitigazione solo come ponte, e dai al ponte una data di scadenza. In concreto: se la tua distribuzione ha un kernel corretto, inizia subito il rollout e verifica uname -r dopo ogni riavvio. Se usi Ubuntu o RHEL, distribuisci oggi lo scarto delle opzioni IP e disabilita MPTCP, poi tratta la fix mancante del kernel come una dipendenza bloccante: controlla il tracker ogni giorno, non ogni settimana. Dai priorità a tutto ciò che è esposto su internet con un listener MPTCP, poi a tutto il resto che accetta TCP in ingresso, cioè quasi tutto. I container non ti salvano: condividono il kernel dell'host, quindi patcha i nodi.

La lezione più profonda è quella che questo bug ci ripropone ogni pochi anni sotto un nuovo numero CVE: le mitigazioni comprano tempo, ma solo le patch chiudono i buchi, e il tempo che le mitigazioni ci comprano si sta accorciando. Costruisci la capacità di fare rollout del kernel rapidi e sicuri prima di averne bisogno, perché la prossima fix da quattro righe è già in coda da qualche parte.