Bad Epoll colpisce il kernel Linux e abilita escalation locale a root

🛡️ Executive Summary

• CVE-2026-46242, nota come Bad Epoll, è una race condition use-after-free nel sottosistema epoll del kernel Linux.
• Un processo locale non privilegiato può corrompere memoria kernel, ottenere lettura arbitraria e arrivare a una shell root.
• Non esiste un workaround semplice: gli amministratori devono applicare il commit correttivo o i backport delle distribuzioni.

Una nuova vulnerabilità nel kernel Linux riporta l’attenzione su uno dei sottosistemi più utilizzati dalle applicazioni moderne: epoll, il meccanismo che consente ai programmi di monitorare molti file descriptor, socket e connessioni in modo efficiente. La falla, denominata Bad Epoll e tracciata come CVE-2026-46242, permette a un utente locale non privilegiato di elevare i propri privilegi fino a root attraverso una race condition di tipo use-after-free. Il bug è stato scoperto da Jaeyoung Chung, ricercatore della Seoul National University, ed è stato presentato con un proof-of-concept funzionante nell’ambito di Google kernelCTF. Il problema nasce da una modifica introdotta nel 2023 nel codice di eventpoll e interessa kernel basati su versioni recenti, con particolare attenzione ai sistemi Linux 6.4+ non ancora corretti e ad alcuni dispositivi Android con kernel moderni. L’impatto è rilevante perché epoll è una funzionalità core del kernel, usata da server, browser, runtime, container e applicazioni di rete: non può essere semplicemente disabilitata senza compromettere il funzionamento del sistema.

La falla in epoll nasce da una race use-after-free

Bad Epoll si manifesta nel percorso di rimozione degli oggetti gestiti da eventpoll, in particolare nella funzione ep_remove(). Secondo la descrizione tecnica del record CVE-2026-46242, il codice cancella il riferimento file->f_ep sotto file->f_lock, ma continua a usare l’oggetto file all’interno della sezione critica. In presenza di un percorso concorrente __fput(), il kernel può osservare uno stato transitorio, saltare la rimozione corretta tramite eventpoll_release_file() e arrivare alla liberazione della struttura tramite f_op->release e file_free(). In termini operativi, un ramo del kernel libera un oggetto mentre un altro ramo continua a scrivere in memoria che non dovrebbe più essere considerata valida. Questa condizione produce una corruzione controllabile della memoria kernel, trasformabile in escalation di privilegi. La vulnerabilità è particolarmente delicata perché coinvolge strutture molto usate, come struct file e struct eventpoll, e perché sfrutta una finestra temporale estremamente ristretta. Il difetto non richiede privilegi amministrativi, moduli kernel esterni o configurazioni rare: basta poter eseguire codice locale.

L’exploit trasforma una finestra minima in root affidabile

La parte più significativa della ricerca di Jaeyoung Chung riguarda l’affidabilità dell’exploit. La race window viene descritta come lunga circa sei istruzioni, quindi teoricamente molto difficile da colpire. Il proof-of-concept supera però il problema con una strategia di retry e con una costruzione controllata di oggetti epoll collegati. L’exploit usa quattro oggetti epoll organizzati in due coppie: una coppia serve a innescare la race, l’altra diventa l’oggetto vittima su cui costruire la primitiva successiva. Da una scrittura use-after-free di 8 byte, l’attacco arriva a controllare un oggetto file e usa una tecnica cross-cache per manipolare il contenuto della memoria kernel. A quel punto ottiene lettura arbitraria attraverso /proc/self/fdinfo, recupera indirizzi utili e costruisce una catena ROP per dirottare il flusso di esecuzione fino a una shell root. Nei target documentati dal repository pubblico, l’exploit raggiunge affidabilità intorno al 99% su un kernel LTS 6.12.67 e circa 98% su una configurazione Container-Optimized OS. Questo dato cambia la valutazione del rischio: non si tratta di un bug teorico, ma di una primitiva locale riproducibile.

Linux desktop, server e container esposti se non aggiornati

L’impatto su sistemi Linux dipende dalla versione del kernel e dai backport applicati dalle distribuzioni. Il bug è stato introdotto dal commit 58c9b016e128 nell’aprile 2023 ed è stato corretto dal commit a6dc643c6931 nell’aprile 2026. Le distribuzioni che hanno già integrato la correzione o un backport equivalente non risultano esposte, mentre sistemi basati su kernel 6.4 o successivi senza patch restano vulnerabili. Per desktop e workstation, lo scenario più evidente è l’escalation di privilegi da parte di un utente locale o di un malware già eseguito con privilegi bassi. Per server e ambienti cloud, il rischio riguarda soprattutto account compromessi, shell limitate, processi applicativi violati e workload containerizzati che possano raggiungere la superficie kernel. Nei container, la vulnerabilità non rimane confinata al namespace applicativo se l’exploit riesce a interagire con il kernel host e a ottenere privilegi superiori. Per questo i provider cloud, le distribuzioni enterprise e gli operatori che gestiscono host multi-tenant devono trattare la patch come prioritaria, anche se l’attacco non è remoto in senso stretto.

Android entra nel perimetro di rischio con kernel recenti

Uno degli aspetti più rilevanti di Bad Epoll è il possibile impatto su Android. Molte vulnerabilità locali del kernel Linux non sono direttamente utili per ottenere root su dispositivi Android perché richiedono moduli non caricati, configurazioni assenti o percorsi non accessibili dal sandboxing mobile. In questo caso, la documentazione del ricercatore evidenzia che il bug può essere attivato anche da contesti particolarmente restrittivi, incluso il renderer sandbox di Chrome. Ciò apre scenari di chain exploit: un difetto nel renderer del browser potrebbe essere combinato con CVE-2026-46242 per passare dall’esecuzione codice nel processo sandboxato all’esecuzione codice nel kernel. Il proof-of-concept Android completo risulta ancora in sviluppo, ma il rischio è concreto per dispositivi con kernel 6.6+, mentre dispositivi basati su kernel 6.1, come alcuni modelli della generazione precedente, non includono il bug introdotto nel 2023. Per l’ecosistema Android, la mitigazione dipende dagli aggiornamenti dei produttori e dalla rapidità con cui i vendor integrano il fix nei bollettini di sicurezza.

Il legame con kernelCTF e il bug trovato da Mythos

La storia di Bad Epoll è significativa anche per il modo in cui è stata scoperta. Jaeyoung Chung ha inviato la vulnerabilità come zero-day a Google kernelCTF, il programma che premia exploit funzionanti contro target kernel controllati. La stessa area di codice era già stata analizzata per un’altra race condition, CVE-2026-43074, individuata dal sistema AI Mythos di Anthropic. Secondo il write-up pubblico, entrambi i bug derivano dallo stesso commit del 2023, ma Bad Epoll è rimasta nascosta più a lungo perché la finestra di gara era minuscola e perché, dopo la correzione dell’altro difetto, non generava segnali evidenti nei detector come KASAN. Questo punto è rilevante per la sicurezza del kernel: anche strumenti avanzati, incluso l’uso di modelli AI per ricerca vulnerabilità, possono individuare una parte del problema e mancare una race condition sfruttabile nello stesso percorso. La vicenda mostra quanto siano difficili da trovare, correggere e validare i bug di concorrenza nel kernel, soprattutto quando coinvolgono refcount, lock, RCU e oggetti riciclati dagli allocator.

La patch corregge il ciclo di vita degli oggetti file

La correzione agisce sul problema centrale: impedire che l’oggetto file venga liberato mentre ep_remove() lo sta ancora utilizzando. Il fix introduce un pin tramite epi_fget() all’inizio del percorso vulnerabile e condiziona la sezione critica al successo di questa acquisizione. Se il pin riesce, file non può raggiungere refcount zero, quindi __fput() non può completare la liberazione mentre il codice sta ancora attraversando strutture collegate come hlist_del_rcu() e f_lock. Se il pin fallisce, significa che il rilascio è già in corso e il codice evita di entrare nel percorso pericoloso. In questo modo vengono chiuse entrambe le condizioni use-after-free descritte nel record CVE. La soluzione è chirurgica, ma il contesto dimostra quanto la gestione del ciclo di vita degli oggetti kernel sia fragile quando strutture condivise vengono toccate da più percorsi concorrenti. Per gli amministratori, però, il dettaglio implementativo conta meno della conseguenza pratica: solo kernel con il commit correttivo o backport ufficiali devono essere considerati protetti.

Aggiornamento urgente e nessun workaround realistico

La mitigazione di Bad Epoll è semplice da formulare ma operativamente urgente: aggiornare il kernel. Non esiste un kill-switch pratico perché epoll è una funzionalità essenziale del sistema operativo. Disabilitarla non è realistico su server, desktop, browser, runtime e applicazioni di rete moderne. Gli amministratori devono verificare la versione del kernel con uname -r, controllare gli advisory della propria distribuzione e applicare i pacchetti correttivi disponibili. Chi compila kernel personalizzati deve includere il commit a6dc643c6931 o una patch equivalente. In ambienti enterprise è consigliabile prioritizzare host multiutente, server esposti, nodi container, workstation sviluppatori e sistemi dove un compromesso locale potrebbe trasformarsi in accesso persistente all’infrastruttura. Dopo l’aggiornamento, il riavvio è necessario per caricare il kernel corretto. Nei casi in cui non sia possibile aggiornare immediatamente, la riduzione del rischio passa da misure compensative limitate: restringere accessi shell, ridurre l’esecuzione di codice non fidato, isolare workload, monitorare tentativi di exploit e accelerare la finestra di manutenzione. La presenza di un proof-of-concept pubblico rende il rinvio della patch una scelta ad alto rischio.