Fragnesia sfrutta Linux kernel: root via page cache corrotta
CVE-2026-46300 permette root su Linux corrompendo file read-only in RAM. PoC pubblico, patch in review e mitigazioni Dirty Frag ancora valide.
Contenuto
Il 13 maggio 2026 il ricercatore William Bowling del team V12 ha divulgato Fragnesia (CVE-2026-46300), una vulnerabilità LPE nel kernel Linux che consente a un attaccante locale non privilegiato di ottenere privilegi di root corrompendo in modo deterministico la page cache in memoria di file in sola lettura come /usr/bin/su.
Il proof-of-concept è già pubblico e la patch candidata è in attesa di review sulla mailing list netdev, lasciando i sistemi esposti fino al rilascio stabile. La notizia è ulteriormente critica perché la stessa mitigazione adottata per Dirty Frag — blacklist dei moduli esp4, esp6 e rxrpc — blocca anche questo attacco, confermando che una correzione d'emergenza può esporre bug latenti nello stesso attack surface.
- CVE-2026-46300 consente escalation a root deterministicamente corrompendo la page cache in RAM di file in sola lettura come /usr/bin/su, senza alterare il contenuto su disco né ricorrere a race condition.
- Il bug risiede in
skb_try_coalesce(), dove la perdita del markerSKBFL_SHARED_FRAGpermette decrittazione AES-GCM in-place su pagine condivise della page cache, trasformando un'operazione di rete in una write primitive su memoria kernel. - Il PoC pubblico di V12 costruisce una lookup table di quasi 256 nonce per ottenere una write primitive byte-per-byte nella page cache e iniettare uno stub ELF di circa 192 byte.
- Le mitigazioni di Dirty Frag (blacklist dei moduli kernel esp4, esp6 e rxrpc) bloccano efficacemente Fragnesia; AlmaLinux ha rilasciato kernel patchati nei repository testing per le release 8, 9 e 10 in anticipo rispetto a CentOS Stream e RHEL.
Da Dirty Frag a Fragnesia: il rischio nascosto nelle patch emergency
Fragnesia, valutata con un punteggio di circa 7.8 sulla scala CVSS, è la terza vulnerabilità LPE emersa in meno di due settimane nello stesso sottosistema XFRM ESP-in-TCP / rxrpc, dimostrando una densità anomala di difetti critici in un'area del kernel fino a poco tempo fa considerata marginale.
Il ricercatore Bowling ha identificato un bug logico latente dal 2013, reso praticamente exploitabile dalla stessa patch che aveva corretto Dirty Frag pochi giorni prima. La patch candidata per Fragnesia riporta esplicitamente due tag Fixes: uno sul commit di Dirty Frag (f4c50a4034e6) e uno su un commit del 2013 (cef401de7be8), confermando che la mitigazione precedente ha alterato le condizioni del codice senza chiudere l'attack surface.
Come skb_try_coalesce() perde il marker e apre la page cache
Il nucleo tecnico di Fragnesia risiede nella gestione dei socket buffer. Durante il coalescing, la funzione skb_try_coalesce() trasferisce paged fragments tra buffer senza propagare il marker SKBFL_SHARED_FRAG, un flag che indica al kernel che il frammento è condiviso esternamente — ad esempio con la page cache di un file in sola lettura.
"The underlying flaw is in the core socket-buffer code:skb_try_coalesce()failed to propagate theSKBFL_SHARED_FRAGmarker when transferring paged fragments between buffers, so the kernel could lose track of the fact that a fragment was externally backed" — AlmaLinux Blog
Quando il sottosistema XFRM ESP-in-TCP procede alla decrittazione AES-GCM in-place, il kernel non riconosce più la natura condivisa della pagina e scrive direttamente nella memoria della page cache. L'errore trasforma così un'operazione di rete legittima in una write primitive deterministica su aree di memoria kernel che dovrebbero essere protette.
L'exploit V12: lookup table e persistenza della cache corrotta
L'exploit pubblico rilasciato da V12 sfrutta la perdita del marker per costruire una lookup table di quasi 256 nonce AES-GCM, ottenendo una write primitive byte-per-byte nella page cache di un file read-only come /usr/bin/su.
Il payload si limita a uno stub ELF di circa 192 byte che, una volta caricato in memoria dal kernel, esegue chiamate come setresuid(0,0,0) per ottenere una shell root. Poiché la modifica interessa esclusivamente la page cache in RAM, il contenuto su disco del binario rimane intatto, insieme ai relativi hash crittografici, ma la cache corrotta persiste fino a eviction o reboot.
Questo rende la compromissione stabile tra invocazioni successive dello stesso binario, senza necessità di race condition e con impatto immediato su ambienti multi-tenant dove un utente locale può corrompere binari condivisi.
Kernel in attesa di merge e prime risposte downstream
Al momento della disclosure, avvenuta il 13 maggio 2026, la patch proposta da Bowling sulla mailing list netdev era ancora in attesa di review e non risultava mergeata stabilmente nell'albero upstream. Nessuna fonte segnala exploitation attive in-the-wild oltre al PoC pubblico, ma la mancanza di indicatori specifici non esclude rischi in ambienti ad alta esposizione.
Microsoft e CloudLinux hanno confermato che gli ambienti che avevano già applicato la mitigazione Dirty Frag non richiedono azioni aggiuntive fino all'installazione di un kernel patchato. Per i team operativi, la necessità di un secondo ciclo di mitigazione in meno di due settimane nello stesso attack surface stressa le infrastrutture che non possono permettersi reboot frequenti.
AlmaLinux ha anticipato CentOS Stream e RHEL pubblicando build corrette nei repository testing per le release 8, 9 e 10, identificate come kernel-4.18.0-553.124.2.el8_10 e successive, kernel-5.14.0-611.54.4.el9_7 e successive, kernel-6.12.0-124.56.2.el10_1 e successive. Non è noto se altre distribuzioni abbiano già reso disponibili pacchetti stabili; Red Hat, al momento, stava ancora valutando l'efficacia delle mitigazioni esistenti.
Cosa fare adesso
- Blacklist immediata dei moduli. Se non già applicata, inserire in blacklist i moduli kernel esp4, esp6 e rxrpc tramite
modprobeo file in/etc/modprobe.d: questa è la stessa mitigazione di Dirty Frag ed è efficace anche contro Fragnesia, interrompendo il vettore prima che raggiunga il bug inskb_try_coalesce(). - Ridurre la superficie locale su container e CI. Su ambienti multi-tenant quali runner di integrazione continua e host containerizzati, limitare l'accesso shell locale e restringere gli unprivileged user namespaces tramite AppArmor o parametri di kernel, tenendo presente che questa difesa fornisce solo una mitigazione parziale e non sostituisce la blacklist dei moduli.
- Pianificare il patching dei kernel. Monitorare i repository della propria distribuzione per l'aggiornamento stabile e, dove disponibile, valutare l'adozione delle build di testing rilasciate da vendor downstream come AlmaLinux; il passaggio a un kernel corretto rimane l'unica soluzione definitiva.
- Verificare la coerenza dei binari critici. Su sistemi sospetti, forzare il flush della page cache tramite reboot o operazioni di eviction, dato che la corruzione introdotta dall'exploit persiste in RAM e può sopravvivere tra invocazioni successive del binario target anche se il contenuto su disco è intatto.
La vicenda di Fragnesia conferma che nel kernel Linux la gestione dei socket buffer e della memoria condivisa tra rete e page cache nasconde interdipendenze difficili da isolare. Per i team operativi, il messaggio è chiaro: le mitigazioni emergenziali vanno trattate come tappabuchi temporanei, non come soluzioni definitive, perché il sottosistema XFRM ESP-in-TCP ha dimostrato di ospitare una catena di bug latenti che le patch affrettate possono risvegliare.
Domande frequenti
La corruzione della page cache si propaga su disco o rimane solo in RAM?
Solo in RAM. L'exploit altera la page cache in memoria, lasciando intatti hash e contenuto on-disk; la persistenza della compromissione è legata esclusivamente alla cache fino a eviction o reboot.
Perché la mitigazione di Dirty Frag blocca anche Fragnesia?
Perché entrambe le vulnerabilità sfruttano lo stesso sottosistema kernel XFRM ESP-in-TCP e gli stessi moduli (esp4, esp6, rxrpc); disabilitandoli si interrompe il vettore di attacco prima che raggiunga il bug in skb_try_coalesce().
È possibile rilevare se il sistema è stato compromesso tramite questo exploit?
Le fonti non indicano indicatori di compromissione specifici oltre alla presenza di un PoC pubblico; la corruzione della page cache è volatile e potrebbe non lasciare tracce persistenti su disco, rendendo la detection principalmente behavior-based.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.