Il kernel Linux torna sotto i riflettori con Bad Epoll, identificata come CVE-2026-46242: una use-after-free legata a una race condition nel sottosistema epoll (eventpoll), il meccanismo che il kernel usa per gestire in modo efficiente migliaia di connessioni e descrittori di file contemporaneamente. Il difetto permette a un processo senza alcun privilegio di ottenere i permessi di root, ossia il controllo completo della macchina. E non riguarda solo server e desktop Linux: colpisce anche i dispositivi Android, che condividono lo stesso kernel.

La radice del problema è un errore introdotto nel 2023: durante la rimozione di una watch epoll, la funzione ep_remove() azzera il riferimento file->f_ep ma continua a usare la stessa struttura file all'interno della sezione critica. Il risultato è un accesso a memoria già liberata che, sfruttando la giusta sequenza di operazioni concorrenti, consente di riscrivere strutture del kernel e scalare i privilegi. La finestra temporale utile all'attacco è minima, larga circa sei istruzioni: un dettaglio che rende la falla difficile da immaginare persino leggendo il codice vulnerabile, ma non impossibile da sfruttare con la giusta tecnica.

A rendere Bad Epoll particolarmente insidiosa è la sua superficie di attacco. La vulnerabilità è stata scoperta e sfruttata dal ricercatore Jaeyoung Chung, che l'ha presentata come 0-day al programma Google kernelCTF (con una ricompensa superiore a 71.000 dollari). Ancora più rilevante: l'exploit può essere innescato dall'interno della sandbox del renderer di Chrome, la barriera che di norma blocca quasi tutti gli altri bug del kernel. In pratica, una falla del browser potrebbe essere concatenata a Bad Epoll per evadere la sandbox e prendere il controllo dell'intero sistema. Sul fronte mobile, il proof-of-concept innesca già la use-after-free su un Google Pixel 10 (kernel v6.6+) e un exploit root completo è in fase di sviluppo.

È però importante evitare allarmismi e attenersi ai fatti. La vulnerabilità, pubblicata sul database NVD il 30 maggio 2026, non ha ancora un punteggio CVSS assegnato, non è inserita nel catalogo CISA KEV e non risultano sfruttamenti attivi confermati in the wild. Richiede inoltre un accesso locale alla macchina. La correzione upstream esiste dal 24 aprile 2026 (commit a6dc643c6931); sono interessati i kernel basati su v6.4 o successivi, mentre le versioni più vecchie basate su v6.1 non sono vulnerabili perché il bug è stato introdotto proprio a partire dalla v6.4. Il vero rischio, in questa fase, è il tempo che intercorre tra la pubblicazione dell'analisi tecnica e del PoC — già disponibili pubblicamente — e il momento in cui ogni distribuzione recepisce e distribuisce la patch ai propri utenti.

Cosa significa per le aziende italiane

Le vulnerabilità di privilege escalation locale come questa vengono spesso sottovalutate perché "richiedono già un accesso alla macchina". È un ragionamento pericoloso. Nella realtà operativa di un'azienda, un accesso a basso privilegio è esattamente ciò che un attaccante ottiene per primo: una web application compromessa, un runner di CI/CD, un container multi-tenant, un account di servizio con permessi limitati. Bad Epoll è il tassello che trasforma quel punto d'appoggio in controllo totale del sistema. Poiché epoll è un componente ubiquo, usato da web server, database, orchestratori e runtime di container, la superficie potenzialmente esposta nel parco Linux di un'organizzazione italiana è enorme: dai server in datacenter alle istanze cloud, fino agli ambienti Kubernetes dove più carichi condividono lo stesso kernel dell'host.

Il caso della sandbox di Chrome merita attenzione particolare per chi gestisce postazioni di lavoro Linux o fleet Android aziendali: qui la catena non parte da un accesso locale, ma potenzialmente da una semplice pagina web malevola, riducendo drasticamente le barriere per l'attaccante. Per un consulente il messaggio è chiaro: la gestione degli aggiornamenti del kernel non è un dettaglio sistemistico, ma un controllo di sicurezza di primo piano.

Il contesto normativo

La gestione tempestiva delle vulnerabilità è oggi un obbligo, non una buona pratica facoltativa. La direttiva NIS2 — recepita in Italia con il D.lgs. 138/2024 — impone ai soggetti essenziali e importanti di adottare misure di gestione del rischio che includono processi strutturati di vulnerability management e patching. Ignorare una falla nota di privilege escalation su sistemi critici, in presenza di una patch disponibile, è precisamente il tipo di negligenza che l'impianto sanzionatorio della normativa punta a scoraggiare. Anche senza sfruttamento confermato, l'esistenza di un PoC pubblico sposta la valutazione del rischio verso l'azione.

Cosa fare subito

  • Aggiornare il kernel Linux all'ultima versione disponibile dalla propria distribuzione (Debian, Ubuntu, RHEL, SUSE e derivate), verificando che il fix del 24 aprile 2026 sia stato recepito nel pacchetto installato.
  • Identificare i sistemi che eseguono kernel basati su v6.4 o successivi: sono i soli interessati. I kernel v6.1 e precedenti non sono vulnerabili.
  • Pianificare il riavvio dei sistemi dopo l'aggiornamento del kernel, o utilizzare il live patching dove supportato, perché la sola installazione del pacchetto non attiva il nuovo kernel.
  • Per i dispositivi Android aziendali, applicare il prossimo bollettino di sicurezza mensile non appena disponibile e gestire l'aggiornamento tramite la soluzione MDM.
  • Rafforzare i controlli sugli ambienti multi-tenant e a container, dove una escalation locale può tradursi in compromissione dell'host condiviso: isolamento dei carichi, principio del privilegio minimo, monitoraggio dei comportamenti anomali dei processi.
  • Tenere aggiornati browser e client sulle postazioni Linux, data la possibilità di concatenare la falla a un'evasione della sandbox di Chrome.