Il 7 maggio 2026 una terza parte non identificata ha rotto l'embargo sulla vulnerabilità Dirty Frag, pubblicando dettagli tecnici e un proof-of-concept funzionante che consente l'escalation a privilegi di root su quasi tutte le principali distribuzioni Linux. Scoperta dal ricercatore Hyunwoo Kim (@v4bel) e segnalata ai maintainer il 30 aprile, la catena combina due primitive di scrittura nella page cache del kernel — CVE-2026-43284 (xfrm-ESP) e CVE-2026-43500 (RxRPC) — per ottenere accesso amministrativo in modo deterministico, senza race condition. Microsoft ha già rilevato attività in-the-wild limitata associabile a questa classe di exploit.
- Dirty Frag è una catena di due vulnerabilità LPE nel kernel Linux: xfrm-ESP (CVE-2026-43284) e RxRPC (CVE-2026-43500), che permettono sovrascrittura selettiva di file setuid nella page cache.
- L'exploit è deterministico, con success rate molto alto e nessuna race condition; il kernel non entra in panic su fallimento, consentendo tentativi ripetuti.
- Il chaining copre i blind spot delle distribuzioni: ESP richiede namespace utente (disponibile su RHEL, bloccato su Ubuntu), RxRPC richiede il modulo rxrpc.ko (caricato di default su Ubuntu, assente su RHEL).
- Microsoft osserva attività in-the-wild limitata con escalation tramite comando 'su' dopo accesso SSH, riconducibile a Dirty Frag o alla vulnerabilità correlata Copy Fail (CVE-2026-31431).
- Le patch mainline sono disponibili ai commit f4c50a4034e6 e aa54b1d27fe0; mitigazione temporanea attraverso blacklist dei moduli esp4, esp6 e rxrpc.
Il meccanismo: scrivere nella page cache come via regia per il root
Il nucleo tecnico di Dirty Frag risiede nella corruzione della page cache attraverso in-place decryption su paged fragments non esclusivamente di proprietà del kernel. Kim ha identificato due sottosistemi — xfrm-ESP IPsec e RxRPC — che permettono questa scrittura mediante pipe pages generate via splice, sendfile e MSG_SPLICE_PAGES. Entrambi i percorsi producono la stessa primitive: un overwrite selettivo di 4 byte su file mappati in memoria, sufficiente per alterare binari setuid e ottenere shell di root.
La variante xfrm-ESP ha radici in un commit di gennaio 2017, medesimo root cause di CVE-2022-27666. La variante RxRPC deriva da un commit di giugno 2023. La loro combinazione non è casuale: costituisce una risposta architetturale alla frammentazione delle difese. Kim ha esplicitamente progettato il chaining perché le restrizioni di una distribuzione diventassero vettore di attacco per l'altra. Su RHEL 10.1, dove la creazione di namespace utente è consentita ma rxrpc.ko non è incluso nel default, l'exploit percorre il ramo ESP. Su Ubuntu, dove AppArmor blocca i namespace utente ma carica rxrpc.ko di default, il percorso RxRPC garantisce la stessa fine.
La geometria delle difese parziali: quando mitigare equivale a esporre
Wiz Research ha confermato l'analisi: le due primitive di scrittura nella page cache permettono la modifica di memoria "non esclusivamente kernel-owned", con conseguente corruzione di file sensibili e escalation a root. L'aspetto paradossale, documentato nel brief tecnico, è che una mitigazione su una distribuzione genera vulnerabilità sull'altra. Ubuntu, nel bloccare i namespace utente, ha indirettamente privilegiato il caricamento di rxrpc.ko come superficie di attacco alternativa. RHEL, nel ridurre il footprint dei moduli, ha lasciato aperto il percorso ESP.
Questa dinamica ha implicazioni immediate per gli ambienti multi-tenant. Su host senza container, Dirty Frag realizza LPE a root con un singolo comando. In container che eseguono workload arbitrari, la stessa catena facilita scenari di container escape — sebbene Wiz noti che l'exploit tipicamente richiede CAP_NET_ADMIN, rendendo meno probabile il successo in ambienti containerizzati con seccomp default attivo.
"Dirty Frag is a vulnerability (class) that achieves root privileges on most Linux distributions by chaining the xfrm-ESP Page-Cache Write vulnerability and the RxRPC Page-Cache Write vulnerability" — Hyunwoo Kim (@v4bel)
Deterministico, pubblico, già osservato: la tripletta che accelera la minaccia
Dirty Frag non introduce una nuova classe di bug, ma eredita e perfeziona le caratteristiche più pericolose dei suoi predecessori. Kim ha sottolineato che si tratta di un "deterministic logic bug that does not depend on a timing window": nessuna race condition, nessun requisito di sincronizzazione, nessun panico del kernel in caso di insuccesso. Il success rate è molto alto. Queste caratteristiche, combinate con la pubblicazione di un PoC funzionante l'8 maggio 2026, abbassano drasticamente la soglia di accesso per attori di minaccia.
Microsoft ha elevato ulteriormente il profilo di rischio, annunciando il monitoraggio di "limited in-the-wild activity" che impiega il comando 'su' per escalation dopo accesso SSH iniziale. La dichiarazione di Microsoft specifica che questa attività "may be indicative of techniques associated with either Dirty Frag or Copy Fail" — la vulnerabilità CVE-2026-31431 precedentemente catalogata nel CISA KEV. Il collegamento non è attributivo ma classificatorio: entrambe le vulnerabilità condividono il meccanismo di scrittura nella page cache e la stessa affidabilità operativa.
Dirty Frag bypassa esplicitamente la mitigazione pubblicamente nota per Copy Fail, la blacklist del modulo algif_aead. Kim ha verificato che l'exploit "can be triggered regardless of whether the algif_aead module is available": sistemi ritenuti protetti dalla mitigazione precedente restano esposti.
Cosa fare adesso
- Applicare le patch mainline ai commit f4c50a4034e6 (CVE-2026-43284) e aa54b1d27fe0 (CVE-2026-43500), disponibili nelle release notes ufficiali del kernel.
- Implementare temporaneamente la blacklist dei moduli esp4, esp6 e rxrpc attraverso i meccanismi di modulo del kernel, riconoscendo che questa azione disabilita funzionalità IPsec e AFS con impatto operativo.
- Verificare che le policy AppArmor o equivalenti per la restrizione dei namespace utente siano effettivamente operative, senza assumere che blocchino autonomamente Dirty Frag a causa del percorso RxRPC alternativo.
- Monitorare i log per pattern di escalation locale tramite 'su' successivi a sessioni SSH, in coerenza con il comportamento segnalato da Microsoft nelle attività in-the-wild.
Perché questa catena cambia il calcolo del rischio Linux
Dirty Frag non rappresenta un'estensione marginale della classe di bug di scrittura nella page cache: ne dimostra la sistematicità. L'adozione consapevole del chaining come strategia di evasione delle mitigazioni distribuzionali indica che i ricercatori, e conseguentemente gli attori di minaccia, stanno trattando le difese parziali come vettori progettabili piuttosto che come ostacoli. Il passaggio da Copy Fail a Dirty Frag, entrambi con PoC pubblici e attività in-the-wild segnalate, suggerisce che questa superficie di attacco rimarrà fertile.
Per le organizzazioni che gestiscono infrastrutture Linux, la tensione è tra velocità di patching e completezza della copertura. Le patch mainline esistono, ma la disclosure forzata dall'embargo rotto ha compresso la finestra di risposta. La necessità di disabilitare moduli core per la rete e il filesystem — non workaround marginali ma interruzioni di funzionalità — indica che la mitigazione temporanea ha costi operativi misurabili. La posta in gioco non è tecnica soltanto: è la sostenibilità del modello di distribuzione delle difese nel kernel Linux, dove la frammentazione delle policy di sicurezza tra vendor sta diventando un moltiplicatore di attacco.
Fonti
- https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html
- https://www.wiz.io/blog/dirty-frag-linux-kernel-local-privilege-escalation-via-esp-and-rxrpc
- https://access.redhat.com/security/cve/cve-2026-43284
- https://www.bleepingcomputer.com/news/security/new-linux-dirty-frag-zero-day-with-poc-exploit-gives-root-privileges/
- https://thecyberexpress.com/dirty-frag-linux-lpe-cve-2026-31431/
- https://nvd.nist.gov/vuln/detail/CVE-2026-43500
- https://kb.cert.org/vuls/id/260001
- https://thehackernews.com/2026/05/cisa-adds-actively-exploited-linux-root.html
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.