Una race condition di sei istruzioni che porta a root
Il 4 luglio 2026 è stata resa pubblica una nuova vulnerabilità di privilege escalation nel kernel Linux, battezzata Bad Epoll e catalogata come CVE-2026-46242. Il difetto permette a un utente locale non privilegiato di ottenere i permessi di root su qualsiasi sistema Linux con kernel 6.4 o successivo, incluse le distribuzioni server più diffuse e i dispositivi Android, dove epoll è un componente del kernel che non può essere disattivato senza rompere il funzionamento del sistema operativo e del browser.
Per chi gestisce infrastrutture Linux in produzione, questo è il tipo di bug che merita attenzione immediata: non richiede alcuna interazione dell’utente privilegiato, non richiede configurazioni particolari, e la finestra di race condition — appena sei istruzioni macchina — non è un ostacolo, perché l’exploit pubblicato la sfrutta con un’affidabilità di circa il 99%.
Cos’è epoll e dove si trova il bug
epoll è il meccanismo con cui il kernel Linux notifica in modo efficiente ai processi eventi di I/O su un gran numero di file descriptor, ed è alla base di praticamente ogni event loop moderno: da Nginx a Node.js, da systemd a Chrome. Proprio perché è così centrale, non è un modulo che si possa scaricare o disabilitare come contromisura temporanea.
Il ricercatore Jaeyoung Chung, dottorando al CompSec Lab della Seoul National University, ha individuato un use-after-free (UAF) nella funzione ep_remove(), quella che ripulisce un file descriptor epoll quando viene chiuso. In condizioni normali, ep_remove() azzera file->f_ep sotto file->f_lock, ma continua a utilizzare l’oggetto file all’interno della sezione critica durante le chiamate a hlist_del_rcu() e spin_unlock(). Se in quella finestra ristrettissima una chiamata concorrente a __fput() osserva un valore transitorio NULL, salta eventpoll_release_file() e procede direttamente a f_op->release, liberando una struttura eventpoll ancora in uso.
Il risultato è memoria del kernel corrotta. Poiché struct file è allocata con SLAB_TYPESAFE_BY_RCU, lo slot liberato può essere immediatamente riciclato da alloc_empty_file(), aprendo la strada a un cross-cache attack: l’attaccante fa in modo che il kernel richiami kmem_cache_free() sulla cache sbagliata, ottenendo il controllo su un oggetto di tipo diverso da quello originariamente allocato in quello slot.
La catena dell’exploit
L’exploit pubblicato da Chung costruisce quattro file descriptor epoll collegati tra loro, organizzati in due coppie: chiudendo una coppia si innesca ripetutamente la race condition, mentre l’altra coppia funge da “vittima”. In questo modo una scrittura UAF di soli 8 byte viene trasformata in un use-after-free completo su un oggetto file tramite cross-cache attack. Da lì, l’attaccante ottiene lettura arbitraria della memoria del kernel attraverso /proc/self/fdinfo e dirotta il flusso di esecuzione con una catena ROP (return-oriented programming) fino a ottenere una shell root.
# Schema semplificato della sequenza (pseudocodice concettuale)
fd1, fd2 = crea_coppia_epoll() # coppia "trigger"
fd3, fd4 = crea_coppia_epoll() # coppia "vittima"
thread_A: chiudi(fd1) # innesca ep_remove() ripetutamente
thread_B: chiudi(fd3) # __fput() concorrente osserva f_ep == NULL
# -> eventpoll_release_file() saltato
# -> free prematuro dell'oggetto eventpoll ancora referenziato
# -> alloc_empty_file() ricicla lo slot -> cross-cache attack
Va sottolineato che questo bug è raggiungibile anche dall’interno della sandbox del processo di rendering di Google Chrome, il che significa che un exploit lato browser potrebbe in teoria essere incatenato a Bad Epoll per ottenere l’esecuzione di codice completa a livello kernel, superando l’isolamento del sandbox.
Perché nemmeno un modello AI lo ha trovato
La storia di questo bug ha un risvolto interessante per chi segue l’evoluzione degli strumenti di analisi automatica del codice. Entrambe le vulnerabilità nascono da un singolo commit del 2023 nello stesso percorso di codice di epoll, lungo circa 2.500 righe. La prima, oggi tracciata come CVE-2026-43074, era stata individuata dal modello AI di Anthropic, Mythos, e già corretta all’inizio del 2026. Bad Epoll è la seconda falla, gemella della prima ma molto più difficile da individuare, che Mythos non aveva notato.
Chung stesso indica due possibili ragioni: la finestra temporale è talmente stretta da rendere difficile “visualizzare” la sequenza esatta degli eventi anche leggendo il codice con attenzione, e l’errore di memoria raramente attiva KASAN, il principale rilevatore di bug del kernel, lasciando pochissime tracce a runtime. È un promemoria utile: gli strumenti di code review basati su AI stanno diventando sempre più capaci di individuare race condition nel kernel, ma i bug di concorrenza restano difficili da scovare a ogni livello, per una macchina come per una persona.
Patch e mitigazioni per i sistemisti
Non esiste un workaround praticabile, perché disabilitare epoll non è un’opzione realistica su un sistema Linux moderno. La correzione definitiva è arrivata con il commit upstream a6dc643c6931, dopo che un primo tentativo di patch non aveva risolto completamente il problema — la correzione corretta è arrivata a circa due mesi dalla divulgazione iniziale.
Le azioni concrete da intraprendere:
- Verificare la versione del kernel in uso: sono interessati i kernel basati su 6.4 e successivi; i kernel 6.1 più datati (compresi alcuni dispositivi Android come il Pixel 8) non sono vulnerabili perché il bug è stato introdotto solo con la 6.4.
- Applicare l’aggiornamento del kernel non appena la propria distribuzione rilascia il backport della patch (Debian, Ubuntu, RHEL e derivate stanno seguendo il processo standard di backport della sicurezza).
- Su flotte Android/embedded, verificare i cicli di aggiornamento del vendor per il patch level di sicurezza corrispondente.
- Non fare affidamento su mitigazioni lato SELinux/AppArmor come sostituto della patch: riducono la superficie d’attacco ma non chiudono la race condition nel kernel.
Vale la pena ricordare che Bad Epoll si inserisce in una serie di bug di privilege escalation del kernel Linux usati storicamente anche per il root di Android, come Bad Binder, Bad IO_uring e Bad Spin. A differenza di altri bug recenti più deterministici (come Copy Fail o Dirty Frag), Bad Epoll appartiene alla categoria più “classica” delle race condition da vincere, nello stile di Dirty Cow del 2016: meno affidabile in teoria, ma qui resa quasi deterministica da un exploit ben costruito.
Conclusione
Per chi amministra server Linux, workstation di sviluppo o flotte Android aziendali, Bad Epoll è un chiaro caso da trattare con priorità alta: patch del kernel disponibile, nessuna mitigazione alternativa valida, e un exploit pubblico con affidabilità prossima al 100%. La lezione più ampia è che, nonostante i progressi degli strumenti di analisi automatica basati su AI nel trovare bug di concorrenza nel kernel, la revisione umana e soprattutto la prontezza nell’applicare le patch di sicurezza restano parte essenziale della gestione del rischio su qualunque infrastruttura Linux.
Fonte: 4sysops.com, con approfondimenti da The Hacker News e Cyber Security News.