Fragnesia è la nuova falla di sicurezza in Linux nata dalla patch di Dirty Frag - l'exploit è già pubblico su GitHub

Sei un amministratore di sistema Linux e hai appena finito di applicare le patch per Dirty Frag? Bene: c'è già un nuovo problema. Si chiama Fragnesia: è stata divulgata pubblicamente con tanto di proof-of-concept su GitHub, ed è nata proprio come effetto collaterale di una delle patch pensate per risolvere Dirty Frag. Un caso da manuale di correzione che genera un nuovo difetto, con implicazioni concrete per chiunque gestisca macchine Linux non ancora aggiornate.

Dirty Frag: il contesto di partenza

Per capire Fragnesia bisogna partire dal suo predecessore: Dirty Frag

» Leggi: Dirty Frag: zero-day Linux senza patch consente accesso root con un solo comando - come proteggersi in attesa della patch

Dirty Frag è stata anche ribattezzata «CopyFail2» perché l'exploit è stato ricostruito tramite reverse engineering del commit di correzione, e rappresenta la naturale evoluzione di Copy Fail. La divulgazione è avvenuta prima della scadenza dell'embargo, a causa della pubblicazione prematura dei dettagli tecnici.

» Leggi: "Copy Fail": nuova vulnerabilità in Linux permette di divenire root senza permesso

Fragnesia: quando la patch crea il problema

Fragnesia è stata scoperta da William Bowling del team di sicurezza V12. Una precisazione doverosa: mentre Hyunwoo Kim è accreditato per Dirty Frag e ha caratterizzato Fragnesia come variante della stessa famiglia, la scoperta tecnica della nuova vulnerabilità è attribuita a Bowling. Ricercatori distinti, difetti correlati ma separati.

Secondo quanto riportato da Kim, Fragnesia è emersa come side effect non intenzionale di una delle patch applicate per correggere le vulnerabilità Dirty Frag originali. Non è un bug trovato per caso in qualche angolo dimenticato del codice: è il figlio diretto di un intervento correttivo andato storto.

La nuova falla risiede nel sottosistema XFRM ESP-in-TCP (ULP - Upper Layer Protocol) e riguarda la gestione impropria dei frammenti di pagina condivisi durante il coalescing degli skb (socket buffer). Quando un socket TCP passa alla modalità ULP espintcp dopo che dei dati di file sono già stati inseriti nella coda di ricezione tramite splice, il kernel tratta erroneamente le pagine del file in coda come testo cifrato ESP. Il risultato: un singolo byte del keystream AES-GCM viene applicato in XOR direttamente nella page cache di un file in sola lettura.

Nessuna race condition. L'exploit è deterministico e affidabile. L'attaccante può alterare qualsiasi singolo byte in un file memorizzato nella cache, impostandolo su un valore arbitrario, un byte per ogni invocazione. Per farlo, l'exploit costruisce una tabella di lookup con 256 voci che mappano tutti i possibili byte del keystream ai nonce corrispondenti.

Dall'alterazione di un byte a una shell di root

La dimostrazione pratica pubblicata con il proof-of-concept è eloquente. L'exploit sovrascrive i primi 192 byte di /usr/bin/su nella page cache con un piccolo stub ELF che invoca setresuid(0,0,0) e poi esegue /bin/sh. Il binario su disco resta completamente intatto - è solo la copia in memoria nella page cache a essere modificata. Questo rende il rilevamento particolarmente ostico con strumenti tradizionali di verifica dell'integrità dei file.

A distinguere Fragnesia da Dirty Frag è anche un altro dettaglio: non servono privilegi a livello host. L'exploit sfrutta i namespace utente e di rete per ottenere la capability CAP_NET_ADMIN all'interno di un namespace isolato. Su distribuzioni come Ubuntu, dove le restrizioni AppArmor sui namespace utente non privilegiati sono attive di default, potrebbero essere necessari bypass aggiuntivi - ma si tratta di una mitigazione parziale, non di una protezione completa.

C'è poi un avvertimento critico per il post-exploit: una volta eseguito l'attacco, /usr/bin/su nella page cache resta modificato e continuerà a generare una shell di root a ogni invocazione fino a quando la cache non viene svuotata. Prima di lasciare la macchina incustodita, gli amministratori devono eseguire echo 1 | tee /proc/sys/vm/drop_caches oppure riavviare.

Il codice del proof-of-concept è disponibile pubblicamente su GitHub

Chi è vulnerabile e quanto è urgente

Qualsiasi kernel Linux antecedente al 13 maggio 2026 è potenzialmente esposto. La patch è una correzione di due righe nel file skbuff.c del kernel, ma al momento della divulgazione non era ancora stata integrata nel kernel mainline né recepita da alcuna release stabile.

Gli scenari di rischio variano in base all'ambiente. Su host senza carichi di lavoro containerizzati, un utente locale può scalare i privilegi fino a root - ed è esattamente ciò che il proof-of-concept pubblicato dimostra. In ambienti con container che eseguono carichi di lavoro di terze parti, si aprono potenziali scenari di container escape, sebbene non sia stato ancora pubblicato alcun proof-of-concept per questo vettore. Negli ambienti Kubernetes con profili seccomp predefiniti, la superficie di attacco è più ridotta ma non eliminata.

La disponibilità pubblica di un proof-of-concept funzionante abbassa drasticamente la barriera di ingresso. Non stiamo parlando di un advisory teorico: il codice per ottenere root è già su GitHub.

Come mitigare

In attesa che le patch vengano recepite dai kernel delle varie distribuzioni, la mitigazione immediata consiste nello scaricare e bloccare i moduli coinvolti:

rmmod esp4 esp6 rxrpc printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf

Canonical suggerisce un approccio analogo, creando il file /etc/modprobe.d/dirty-frag.conf con le stesse direttive. Un punto fondamentale: le vulnerabilità nei due sottosistemi sono indipendenti. Disabilitare solo ESP o solo RxRPC lascia l'altro percorso sfruttabile. Vanno bloccati entrambi.

Questa mitigazione ha però un costo. Chi utilizza IPsec - ad esempio tramite StrongSwan per connessioni VPN - o il file system AFS tramite RxRPC subirà regressioni funzionali. Per questi ambienti non esistono compromessi ragionevoli: l'unica strada è applicare le patch del kernel non appena disponibili dal proprio distributore, come raccomanda esplicitamente anche Wiz.

La patch che genera la vulnerabilità

Il dato più significativo di questa vicenda non è tanto la singola falla, quanto la dinamica che l'ha prodotta. Fragnesia è il prodotto diretto di un intervento correttivo su Dirty Frag: un fix che, risolvendo un problema, ne ha introdotto un altro nello stesso sottosistema, con lo stesso meccanismo di corruzione della page cache e lo stesso approccio deterministico all'exploit.

Le due famiglie condividono la stessa classe - corruzione della page cache del kernel - e vengono entrambe paragonate a vulnerabilità precedenti come Dirty Pipe e Copy Fail. La differenza è che Fragnesia abbassa ulteriormente la soglia: niente privilegi host, tutto attraverso namespace isolati.

Per gli amministratori Linux il messaggio è scomodo ma chiaro. Le patch per Dirty Frag non bastano: bisogna verificare che anche la correzione per Fragnesia sia applicata, e nel frattempo procedere con le mitigazioni a livello di modulo. Due vulnerabilità in una settimana nello stesso sottosistema, con la seconda nata dalla correzione della prima, ricordano quanto sia delicata la manutenzione del codice del kernel nelle aree che gestiscono la frammentazione dei pacchetti e la page cache. Un equilibrio che, evidentemente, basta poco per rompere.

Fonti: phoronix.com, wiz.io