Se hai letto il nostro articolo su Copy Fail la settimana scorsa e hai tirato un sospiro di sollievo dopo aver aggiornato il Kernel, preparati: c’è già un successore. Si chiama Dirty Frag ed è registrata come l’unione di CVE-2026-43284 e CVE-2026-43500. A scoprirla è stato il ricercatore Hyunwoo Kim (noto online come “@v4bel”). L’exploit pubblico è disponibile su GitHub, e una Proof of Concept funzionante è già stata eseguita con successo su Debian, Ubuntu, RHEL, e molte altre distribuzioni.

Dirty Frag appartiene alla stessa classe di bug di Copy Fail e della storica Dirty Pipe: vulnerabilità che permettono a un processo non privilegiato di scrivere nella page cache del Kernel, modificando file che non possiede, ma a cui ha accesso in memoria. Di seguito mostriamo l’exploit in atto su vari sistemi Linux.

L’attacco risiede in una catena di due vulnerabilità distinte che, combinate insieme, consentono di ottenere i privilegi di root in varie modalità.

Il punto di partenza è la struttura sk_buff, ovvero il buffer che il Kernel Linux usa per gestire i pacchetti di rete. Questa struttura contiene un campo chiamato frag, che può contenere riferimenti a pagine della page cache. Il problema è che non viene verificata correttamente la proprietà esclusiva di queste pagine prima di permetterne la scrittura.

La prima variante sfrutta il sottosistema xfrm-ESP (il modulo di cifratura usato da IPsec e dalle VPN). Richiede la capacità di creare un network namespace isolato, il che in certi ambienti è già possibile senza privilegi particolari, ma non ovunque.

La seconda variante sfrutta invece il modulo RxRPC, usato dal protocollo di rete AFS. Questa non richiede alcun namespace e funziona anche dove la prima sarebbe bloccata.

Usandole insieme in un unico binario, l’exploit copre praticamente qualsiasi configurazione. Il bersaglio della PoC è, come nel caso di Copy Fail, un binario setuid del sistema: pochi byte riscritti nella page cache nel punto corretto, e si ottiene una shell root. La severity assegnata è critica: 79.23 secondo il punteggio sistemico dell’ACN.

Questa vulnerabilità ha quindi molto in comune con Copy Fail.

Come Copy Fail, anche Dirty Frag si distingue dalla maggior parte delle Local Privilege Escalation per alcune caratteristiche che la rendono difficile da ignorare. Non si basa su race condition e l’exploit funziona in modo deterministico: se il sistema è vulnerabile, l’escalation riesce e non causa crash del sistema pur lavorando in un contesto privilegiato. In caso di fallimento, il Kernel non va in Kernel panic. Questo rende la vulnerabilità silenziosa e difficile da rilevare.

Le distribuzioni confermate come vulnerabili includono:

• Debian 13 con Kernel 6.12.73-1
• Ubuntu 24.04.4 con Kernel 6.17.0-23-generic
• RHEL 10.1 con Kernel 6.12.0-124.49.1.el10_1
• CentOS Stream 10, AlmaLinux 10, Fedora 44, openSUSE Tumbleweed

Non risultano invece vulnerabili le versioni del Kernel precedenti alla 6.5, e le versioni patchate: 6.6.138+, 6.12.87+, 6.18.28+ e 7.0.5+.

Le priorità più alte riguardano, come per la precedente vulnerabilità, i cluster Kubernetes multi-tenant (che sono già soggetti ad attacchi mirati), i runner CI/CD che eseguono codice da pull request esterne, i cluster HPC e le piattaforme SaaS che eseguono codice degli utenti in container.

La fix ufficiale è stata integrata nel codice sorgente del Kernel Linux in data 8 maggio 2026, ma non è ancora disponibile nei repository delle principali distribuzioni tramite i normali canali di aggiornamento.

La variante xfrm-ESP (CVE-2026-43284) ha infatti una patch mainline disponibile: il commit f4c50a4034e6 è stato integrato nell’albero principale di Torvalds l’8 maggio 2026.

La variante RxRPC (CVE-2026-43500) è invece (al momento della stesura di questo articolo) come segnalato dalla pagina GitHub dell’autore della PoC, ancora completamente priva di patch: la CVE è stata riservata per il tracciamento, ma al momento non esiste alcuna correzione in nessun albero del Kernel. Questo significa che anche quando le distro inizieranno a distribuire la fix per la prima variante, il sistema rimarrà esposto alla seconda finché non arriverà anche quella.

Nel frattempo, la mitigazione consigliata è disabilitare i moduli vulnerabili con il comando:

$ sudo 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; true"

Per verificare che i moduli siano effettivamente disabilitati il seguente comando non deve restituire nulla (si raccomanda anche un riavvio del sistema):

$ lsmod | grep -E "esp|rxrpc"

Aggiornate non appena i pacchetti ufficiali saranno disponibili nei repository della vostra distribuzione. E tenetevi pronti: due vulnerabilità critiche che sfruttano lo stesso exploit sulla page cache in due settimane suggeriscono che questa classe di bug non ha ancora finito di fare danni.

Ne spunteranno altre a breve?