È stata scoperta una nuova vulnerabilità nel kernel Linux, denominata Fragnesia e identificata con il codice CVE-2026-46300. La problematica rientra nella stessa categoria di attacchi alla cache delle pagine, come Copy Fail e Dirty Frag recentemente discussi, ma non è una ripubblicazione di un vecchio errore: si tratta di un difetto specifico nel codice XFRM ESP-in-TCP.
La vulnerabilità è stata scoperta dal ricercatore William Bowling del team V12 Security. Secondo la descrizione pubblicata, Fragnesia consente a un utente locale non privilegiato di modificare il contenuto di file accessibili solo in lettura, nella memoria della cache delle pagine, e grazie a ciò di eseguire codice con permessi di root. A differenza di molti vecchi exploit LPE, l'attacco non richiede condizioni di gara ed è descritto dagli studiosi come deterministico.
Tecnicamente, il problema è legato al fatto che, durante la fusione dei buffer di rete, il kernel potrebbe aver perso il segnale che un frammento di dati fosse "condiviso" e correlato a una pagina di memoria esterna, inclusa la cache delle pagine. Nel patch proposto, questo è descritto come un errore in skb_try_coalesce(): nel trasferimento di frammenti paginati da un sk_buff all'altro, non veniva mantenuto il flag SKBFL_SHARED_FRAG. Di conseguenza, il codice ESP successivo potrebbe erroneamente considerare il buffer sicuro per la modifica.
L'effetto pratico è che i dati precedentemente inseriti nella coda TCP da un file, dopo aver switched il socket in modalità espintcp, potrebbero essere stati elaborati dal kernel come testo cifrato ESP. Durante la decrittazione AES-GCM, i byte venivano modificati direttamente nella pagina della cache, collegata al file. Questo non modifica il file su disco, ma altera la sua rappresentazione in memoria fino a quando la pagina non viene rimossa dalla cache.
Nella dimostrazione di attacco pubblicata, come obiettivo è stata utilizzata /usr/bin/su: l'exploit ha modificato i primi byte del file binario nella cache delle pagine e ha poi eseguito una copia modificata in memoria, ottenendo una shell con permessi di root. Il file originale su disco è rimasto invariato, il che rende il problema particolarmente sgradevole da diagnosticare: le tracce di sfruttamento possono scomparire dopo la pulizia della cache delle pagine o il riavvio.
Fragnesia è emersa meno di una settimana dopo Dirty Frag. In V12 si sottolinea che si tratta di un errore distinto nella stessa superficie d'attacco — ESP/XFRM — e non di un rinominare una vulnerabilità già corretta. Phoronix osserva inoltre che al momento della pubblicazione era disponibile un proof-of-concept e che la correzione era un piccolo patch a net/core/skbuff.c, che non era ancora stato immediatamente incluso nei rami principali del kernel.
Canonical ha assegnato CVE-2026-46300 alta priorità a Ubuntu, indicando la ragione come «escalation di privilegi locale banale». Nella pagina di sicurezza di Ubuntu per i kernel interessati, al momento dell'aggiornamento del 13 maggio, il loro stato era «Needs evaluation», e nella nota si specifica che il problema è presente anche nel modulo ESP del kernel e può essere temporaneamente mitigato nello stesso modo di Dirty Frag.
Debian Security Tracker al momento del controllo etichettava come vulnerabili i kernel nei rami bullseye, bookworm, trixie, forky e sid; per il pacchetto linux in unstable, la versione corretta non era ancora stata specificata.
La misura di protezione temporanea rimane la stessa di Dirty Frag: disabilitare il caricamento dei moduli esp4, esp6 e rxrpc, se non necessari al sistema. Questo potrebbe compromettere il funzionamento dei tunnel IPsec nei nodi in cui sono utilizzati kernel ESP, strongSwan, Libreswan o configurazioni simili, quindi su gateway VPN tale misura deve essere applicata solo dopo aver valutato le conseguenze.
Esempio di mitigazione temporanea per gli amministratori:
sudo sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf" sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
Se si sospetta che il sistema possa già essere stato attaccato, bloccare i moduli non è sufficiente: poiché la dimostrazione pubblica modifica il file eseguibile proprio nella cache delle pagine, gli amministratori raccomandano di svuotare la cache delle pagine o riavviare il sistema dopo aver applicato le misure di protezione. CloudLinux specifica chiaramente che dopo l'exploitation /usr/bin/su potrebbe rimanere modificato in memoria fino a quando non vengono espulsi i relativi pagine.
Per rimuovere la regola temporanea dopo aver installato il kernel corretto, si può eliminare il file creato:
sudo rm /etc/modprobe.d/dirtyfrag.conf
La raccomandazione principale rimane la stessa: installare il kernel corretto dal proprio distribuzione e riavviare il sistema. Prima dell'aggiornamento, i server multiutente, i CI runner, l'hosting condiviso, le farm di build container e qualsiasi macchina in cui utenti non privilegiati o parzialmente fidati possono eseguire codice locale rappresentano il rischio maggiore.
Fonte: linux.org.ru
