Cosa fa Bad Epoll e chi è esposto

Bad Epoll è una corsa use-after-free in epoll, la funzione standard di Linux che permette a un programma di sorvegliare molti file e connessioni insieme. Quando due liste eventpoll si sorvegliano a vicenda e vengono chiuse nello stesso istante, una libera un oggetto interno mentre l'altra vi sta ancora scrivendo, e quella breve collisione consente a un processo senza privilegi di corrompere la memoria del kernel e salire a root. L'exploit pubblico legge la memoria del kernel, dirotta una chiamata indiretta e costruisce una catena orientata al ritorno fino a una shell di root.

L'esposizione è ampia. Qualsiasi sistema Linux su un kernel basato sulla versione 6.4 o successiva è colpito finché non viene applicata la patch, il che comprende desktop, server e telefoni Android come il Pixel 10 su kernel 6.6. I kernel della vecchia linea 6.1 non sono colpiti, perché il difetto è stato introdotto in una modifica del 2023 arrivata in 6.4. Non risultano ancora attacchi reali, ma con codice funzionante su GitHub la finestra tra pubblicazione e abuso è breve, ed epoll è usato ovunque, quindi non si può semplicemente disattivare.

Il bug che un audit di IA non ha colto

La lezione più netta sta in come il bug è stato trovato. Sia Bad Epoll sia il suo gemello, CVE-2026-43074, risalgono alla stessa singola modifica del 2023 al codice di epoll. Un audit del codice automatizzato ha colto il primo della coppia all'inizio del 2026, e la sua correzione è arrivata. Non ha colto Bad Epoll. Quello è stato trovato alla vecchia maniera, da una persona: Jaeyoung Chung della Seoul National University lo ha segnalato al kernelCTF di Google come invio zero-day il 6 luglio 2026, con un exploit abbastanza affidabile da essere descritto come quasi certo.

Leggetelo con attenzione prima di concludere che l'IA ha chiuso la caccia ai bug del kernel. La revisione automatica è davvero utile e ha tolto dall'albero un bug di root attivo. Ma un solo commit rischioso ha prodotto due difetti sfruttabili, la passata automatica ne ha preso uno e lasciato l'altro, e quello lasciato era quello che dà root. La revisione con IA alza la base; non rende l'applicazione delle patch un passo facoltativo, e non significa che un commit che ha benedetto sia pulito.

Cosa applicare questa settimana

La correzione è nel kernel mainline dal 24 aprile, come commit upstream a6dc643c6931, ma non è lo stesso che la correzione arrivi sulle vostre macchine. Molte distribuzioni non l'hanno ancora retroportata, quindi il rischio reale vive nel divario tra corretto in mainline e applicato sulla flotta. Applicate l'ultimo aggiornamento del kernel della vostra distribuzione appena esce, e sul Pixel 10 e altri dispositivi su kernel 6.6 l'aggiornamento di sicurezza di Google quando disponibile.

Date priorità a chi può accedere. Il pericolo di un bug da locale a root è massimo dove utenti non fidati o numerosi condividono un host: hosting condiviso, runner di integrazione continua, container multi-tenant e macchine di sviluppo dove un singolo account compromesso non deve diventare l'intera macchina. Controllate la versione del kernel, trattate come esposto tutto ciò che è su 6.4 o successivo finché non è applicata la patch, e usate questo come spunto per rivedere altre correzioni nate dalla stessa modifica di epoll del 2023.

Da leggere ora: Un bug di root Linux ora colpisce server e Android  |  Questo malware cancella prima i tuoi backup