Dirty Frag: il bug kernel Linux che bypassa ogni scanner container

Il 7 maggio 2026 è stata forzata la pubblicazione di Dirty Frag, una vulnerabilità di privilege escalation nel kernel Linux scoperta dal ricercatore Hyunwoo Kim e divulgata dopo la rottura dell'embargo. Il bug, raccolto sotto tre identificatori CVE distinti, permette a un attaccante locale con privilegi minimi di alterare file read-only in memoria attraverso sottosistemi di networking, ottenendo accesso root. La posta in gioco supera il singolo sistema: in ambienti containerizzati, la vulnerabilità risiede nel kernel del nodo host, rendendo invisibile agli strumenti di scanning delle immagini Docker un percorso di attacco che può portare al container escape.

Come funziona la corruzione della page cache

Il kernel Linux utilizza la chiamata di sistema splice() per trasferire dati dalla page cache ai sottosistemi di networking senza copia fisica in memoria. Questo meccanismo, ottimizzato per le prestazioni, espone buffer condivisi tra il filesystem e lo stack di rete.

Secondo l'advisory di Aikido Security, "neither the ESP nor the RxRPC path checks whether the memory is shared before writing to it". Il risultato è che un attaccante può indurre questi percorsi a scrivere direttamente su pagine appartenenti a file read-only caricati in cache. Il file su disco non viene mai modificato, ma le successive letture — incluse le esecuzioni di binari come /usr/bin/su — recuperano la copia corrotta dalla RAM.

Questo schema spiega perché gli strumenti di integrità dei file tradizionali falliscono: le firme crittografiche calcolate sul disco restano valide, mentre il codice eseguito in memoria è già compromesso. L'assenza di race condition, tipica di molti bug kernel, rende l'exploit altamente riproducibile e prevedibile.

Fragnesia: quando il fix introduce un nuovo vettore

La storia di Dirty Frag non si conclude con il primo patchset. Il fix iniziale per CVE-2026-43284 introdotteva un marker "fragment is shared" per bloccare le scritture non autorizzate. Tuttavia, una variante follow-on denominata Fragnesia (CVE-2026-46300) ha dimostrato che questo meccanismo di difesa poteva essere aggirato.

Come documenta Aikido Security, "an old bug from 2013 in the code that merges packet fragments together quietly drops that marker. It sat harmless for thirteen years because nothing depended on it". Il bug dormiente, introdotto nel 2013, ha acquisito rilevanza critica solo dopo che il fix per Dirty Frag ha reso il marker un punto di sicurezza essenziale. La variante Fragnesia sfrutta specificamente il percorso ESP-in-TCP, estendendo la superficie di attacco oltre il caso originale.

Questa sequenza — vulnerabilità, fix incompleto, nuova variante — solleva questioni sulle revisioni di sicurezza dei patch kernel, dove la compatibilità con decenni di codice legacy spesso oscura le interazioni tra modifiche apparentemente indipendenti.

"A read-only file should stay read-only. Dirty Frag gets the Linux kernel to edit its cached copy anyway."
— Aikido Security advisory

Il cieco della container security: perché gli scanner non vedono

L'angolo editoriale richiesto dal dossier — e confermato dai fatti tecnici — è che Dirty Frag espone un cieco strutturale nella sicurezza dei workload containerizzati. Gli strumenti di scanning delle immagini Docker, dai motori SCA ai vulnerability scanner per registries, analizzano il contenuto statico delle immagini: pacchetti, librerie, configurazioni. Nessuno di questi strumenti ispeziona il kernel del nodo host su cui il container verrà eseguito.

In un cluster Kubernetes, OpenShift o Docker Swarm, il kernel è una risorsa condivisa tra tutti i pod e i servizi. Una vulnerabilità come Dirty Frag annulla il confine logico tra container: un processo con privilegi minimi all'interno di un pod isolato può corrompere la page cache del nodo, compromettendo l'integrità di ogni altro workload sullo stesso host. Il container escape, in questo scenario, è una conseguenza diretta della natura del bug piuttosto che di una configurazione errata.

Le aziende che hanno investito pesantemente in pipeline di sicurezza per le immagini — scanning in CI/CD, policy di admission, runtime enforcement — si trovano a gestire un rischio che questi controlli non possono nemmeno rilevare. La catena di approvvigionamento del kernel host, spesso gestita separatamente dai team platform o dai cloud provider, è diventata il collo di bottiglia non monitorato della sicurezza cloud.

Cosa fare adesso

Le azioni prioritarie derivano direttamente dai dati del dossier:

• Patchare il kernel del nodo host, non ricostruire le immagini Docker: il bug risiede nel kernel, non nel contenuto dei container. Le errata Red Hat (RHSA-2026:16062, RHSA-2026:16195/16196, RHSA-2026:17795) forniscono i riferimenti per le distribuzioni supportate.
• Verificare che CVE-2026-43500 non sia presente nei sistemi interessati: Red Hat dichiara esplicitamente che questo identificatore non affetta i suoi prodotti, ma altre distribuzioni con il modulo rxrpc caricato potrebbero essere esposte.
• Controllare la presenza di kernel con patch incomplete: la variante Fragnesia dimostra che i fix iniziali possono essere insufficienti. I kernel aggiornati tra maggio e giugno 2026 devono includere il secondo patchset per CVE-2026-46300.
• Rivedire i template e le immagini base che potrebbero rimanere in servizio su nodi non ancora aggiornati: la persistenza di workload su kernel vecchi espone il cluster anche se le immagini sono apparentemente aggiornate.

L'attività in-the-wild e i limiti della visibilità

Microsoft ha riportato attività in-the-wild limitata, con attacchi che sfruttano su per l'escalation dei privilegi. L'incertezza residua è significativa: la stessa fonte non distingue con sicurezza se le intrusioni osservate siano Dirty Frag o Copy Fail, un predecessore con meccanismo simile. Questa sovrapposizione diagnostica limita la capacità di stimare la prevalenza reale dell'exploit e di correlare gli incidenti osservati.

Il codice PoC pubblico, con exploit funzionanti per Kubernetes, abbassa la barriera all'adozione da parte di attori non sofisticati. La combinazione di exploit deterministico e ambienti cloud altamente popolati crea condizioni di rischio che non dipendono dalla sofisticazione dell'attaccante.

Perché la sicurezza container deve guardare oltre il container

Dirty Frag non è una vulnerabilità di Docker, Kubernetes o di qualsiasi runtime container. È una vulnerabilità del kernel Linux che rende visibile l'architettura di confinamento stessa. La lezione più fredda è che gli investimenti nella sicurezza delle immagini — scanner, firme, policy — non proteggono da un kernel host compromesso.

La variante Fragnesia aggiunge un ulteriore strato di cautela: anche i fix possono nascondere interazioni con codice legacy dormiente, e la mancanza di attività in-the-wild confermata non garantisce assenza di rischio. Per i team di sicurezza cloud, la priorità si sposta dalla pipeline CI/CD al lifecycle management del kernel, un dominio spesso gestito con cadenze e responsabilità diverse.

Il confine tra sicurezza dell'applicazione e sicurezza dell'infrastruttura, già sfumato nei deployment containerizzati, qui si dissolve completamente. Chi gestisce cluster produttivi deve ora verificare non solo cosa gira nei container, ma su quale kernel, con quale patch, e con quale consapevolezza delle varianti non ancora catalogate.

Fonti

• https://www.aikido.dev/blog/dirty-frag
• https://access.redhat.com/security/cve/cve-2026-43284
• https://memeburn.com/dirty-frag-linux-vulnerability-detected-hands-hackers-instant-root-access/
• https://socprime.com/blog/cve-2026-43500-and-cve-2026-43284-analysis/
• https://nvd.nist.gov/vuln/detail/CVE-2026-43284
• https://nvd.nist.gov/vuln/detail/CVE-2026-43500
• https://nvd.nist.gov/vuln/detail/CVE-2026-46300
• https://www.aikido.dev/blog/securing-docker-images

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti