Se pensavate che dopo Copy Fail e Dirty Frag i vostri sistemi fossero finalmente al sicuro, preparatevi ad un’altra CVE. Si chiama Fragnesia, è registrata come CVE-2026-46300 ed è stata pubblicata da William Bowling, Head of Assurance di Zellic, insieme a una Proof of Concept funzionante.

La buona notizia: appartiene alla stessa classe di bug che ormai conoscete bene. La cattiva: è un bug indipendente con la propria patch separata, e colpisce tutti i Kernel Linux rilasciati prima del 13 maggio 2026.

Fragnesia appartiene infatti alla classe di vulnerabilità di Copy Fail e Dirty Frag, il meccanismo di fondo è sempre lo stesso: sfruttare la page cache del Kernel per scrivere byte arbitrari in file di sola lettura, senza essere root.

Come nei casi precedenti, il bersaglio della PoC è sempre il binario /usr/bin/su, che gli attaccanti ormai sembrano usare come trampolino di lancio appena trovata una falla nel meccanismo della page cache.

La differenza rispetto a Dirty Frag sta nel vettore: la CVE precedente sfruttava una catena di due vulnerabilità distinte (xfrm-ESP + RxRPC) che richiedevano di essere combinate insieme. Fragnesia è invece un bug autonomo nel sottosistema XFRM ESP-in-TCP, parte dell’implementazione di IPsec in Linux, utilizzato per incapsulare il traffico IPsec ESP all’interno di una connessione TCP.

Bowling infatti spiega:

Fragnesia is a member of the Dirty Frag vulnerability class. This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.

Fragnesia fa parte della classe di vulnerabilità Dirty Frag. È un bug separato nell’ESP/XFRM che ha ricevuto la propria patch. Si trova però allo stesso livello e la mitigazione è la stessa di dirtyfrag.

Inoltre, come Copy Fail e Dirty Frag, l’exploit non si basa su race condition e non causa crash del Kernel: lavora in modo silenzioso, senza Kernel panic in caso di fallimento. Come per le precedenti CVE, le priorità più alte riguardano i soliti cluster Kubernetes, i runner CI/CD e i sistemi basati su container e namespace.

Per chi volesse testare la vulnerabilità, l’exploit “oneliner” è il seguente:

$ git clone https://github.com/v12-security/pocs.git && cd pocs/fragnesia && gcc -o exp fragnesia.c && ./exp

La prima cosa da fare per proteggersi è aggiornare il Kernel non appena i pacchetti saranno disponibili nei repository della vostra distribuzione. La fix ufficiale è già presente nell’albero principale.

Se non potete aggiornare immediatamente, la mitigazione è la stessa già consigliata per Dirty Frag: disabilitare i moduli Kernel vulnerabili. Tenete presente che questo interromperà il normale funzionamento delle VPN IPsec sulla macchina.

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

Si raccomanda come sempre un riavvio del sistema dopo aver applicato la mitigazione.

La domanda finale, che ci siamo posti in precedenza e ripetiamo ora, è sempre la stessa: si fermerà mai il pattern?

Copy Fail, Dirty Frag, Fragnesia: tre vulnerabilità critiche nella stessa classe, tutte e tre con PoC pubblica, tutte e tre nelle ultime settimane. Il pattern sembra essere sempre lo stesso e la page cache continua a essere una superficie fertile. Serve davvero un rework architetturale del suo funzionamento, o basterà rattoppare i singoli moduli uno per volta?