In quello che potremmo ormai definire l’appuntamento settimanale con le nuove falle in Linux, pochi giorni dopo Januscape e GhostLock, ecco un articolo dedicato ad un’altra, nuova, vulnerabilità nel Kernel, soprannominata Bad Epoll, che permette a un utente locale senza privilegi di diventare root. Colpisce server, desktop e dispositivi Android, e il PoC pubblico raggiunge un’affidabilità del circa il 99% su una macchina vulnerabile.

A scoprirla è stato Jaeyoung Chung, dottorando al Computer Security Lab della Seoul National University, che l’ha sottoposta al programma kernelCTF di Google. La falla, tracciata come CVE-2026-46242, è, ancora, una race condition use-after-free nel subsystem epoll, il meccanismo con cui il kernel permette a un programma di monitorare molti file descriptor contemporaneamente senza doverli interrogare uno a uno.

Il problema sta nella funzione ep_remove(), che si occupa di ripulire un file descriptor quando smette di essere monitorato da epoll. Questa funzione azzera il collegamento epoll del file e continua a usarlo, mentre una release concorrente dello stesso file, vedendo quel collegamento già azzerato, libera l’oggetto sottostante mentre è ancora in uso. Il risultato è un puntatore che continua a essere usato dopo che l’oggetto a cui punta non esiste più: un classico use-after-free, solo che qui succede dentro il kernel.

Chi ha ricostruito l’exploit ha trasformato questa scrittura scorretta di 8 byte in qualcosa di molto più serio, passo dopo passo: prima ottiene il controllo di un oggetto struct file, poi da lì arriva a leggere memoria kernel arbitraria, e infine costruisce una catena ROP (ovvero Return-Oriented Programming, uno degli attacchi più affascinanti nell’ambito della memory corruption) per dirottare il flusso di esecuzione e ottenere una shell root. La tecnica pubblicata usa quattro file descriptor epoll collegati a coppie: una coppia fa scattare ripetutamente la race, l’altra fa da vittima, e il tentativo viene ripetuto in loop finché non va a segno, senza mai far crashare il kernel nel frattempo.

La Proof of Concept è disponibile con demo su GitHub ed un esempio dell’attacco è il seguente:

Questa vulnerabilità è particolarmente interessante perché può colpire anche sistemi Android, a differenza di altre. Il ricercatore infatti afferma:

A rare bug that can root Android. Most Linux privilege-escalation bugs cannot root Android at all. Copy Fail and its variants, for example, need modules that Android never loads. Out of the roughly 130 vulnerabilities exploited on Google's kernelCTF, only about ten are candidates for rooting Android. Bad Epoll is one of them.

Un bug raro, capace di ottenere root anche su Android. La maggior parte dei bug di privilege escalation su Linux non riesce a ottenere root su Android. Copy Fail e le sue varianti, ad esempio, richiedono moduli che Android non carica mai. Delle circa 130 vulnerabilità sfruttate su kernelCTF di Google, solo una decina sono candidate per fare root su Android. Bad Epoll è una di queste.

La storia di questo bug è particolare. Il codice vulnerabile nasce da un singolo commit del 2023 che ha introdotto due race condition distinte nello stesso percorso di codice di epoll. La prima, CVE-2026-43074, è stata trovata da Mythos, il modello AI di Anthropic. Bad Epoll è la seconda, più difficile da individuare, perché una volta corretta la prima, non fa scattare KASAN (il rilevatore dinamico di errori di memoria del kernel Linux), lasciando poche tracce a runtime. Anche una volta segnalata, non è stata semplice da sistemare: il primo tentativo di patch dei maintainer non ha risolto del tutto il problema, e una correzione definitiva è arrivata solo due mesi dopo la prima segnalazione, un’eternità per un kernel che di solito gestisce le questioni di sicurezza con urgenza.

Le versioni interessate sono ampie: le versioni del Kernel Linux dalla 5.10 alla 6.11 risultano confermate come affette, e distribuzioni come Ubuntu 24.04/25.10/26.04, Debian Trixie/Forky/Sid, Amazon Linux 2023 e Red Hat Enterprise Linux 9 e 10 sono coinvolte. Il fix upstream è arrivato con il commit a6dc643c6931, che fissa il file prima di entrare nella sezione critica, così da impedire che venga rilasciato mentre la pulizia è ancora in corso. Non esiste una mitigazione pulita lato configurazione: epoll non si può disabilitare senza rompere gran parte del sistema operativo e dei browser moderni, quindi l’unica strada è applicare la patch.

Chi non riesce a patchare subito può solo ridurre la superficie di rischio: isolare l’esecuzione di codice non fidato, restringere l’accesso di utenti locali dove possibile, e verificare con l’advisory del proprio vendor che il Kernel installato porti davvero la correzione, invece di fidarsi solo del numero di versione o della data di build. Da segnalare la reazione tempestiva di AlmaLinux, che ha deciso di non aspettare l’aggiornamento a monte di CentOS Stream/RHEL: il team ha backportato la correzione su tutti i branch affetti e l’ha già messa in produzione nel proprio repository di test, con l’intenzione di promuoverla agli repository stabili non appena la community ne conferma la stabilità.

Come per Januscape, il fatto che il bug sia rimasto lì per anni, in codice open-source che chiunque poteva leggere, dice più sul tempo e l’attenzione che servono a scovare questi problemi, verosimilmente mediante AI, che sulla trasparenza del codice in sé.