O que Bad Epoll faz e quem está exposto

Bad Epoll é uma corrida use-after-free em epoll, a funcionalidade padrão do Linux que permite a um programa vigiar muitos ficheiros e ligações ao mesmo tempo. Quando duas listas eventpoll se vigiam mutuamente e são fechadas no mesmo instante, uma liberta um objeto interno enquanto a outra ainda escreve nele, e essa breve colisão permite a um processo sem privilégios corromper memória do kernel e subir a root. O exploit público lê memória do kernel, sequestra uma chamada indireta e constrói uma cadeia orientada a retorno até uma shell de root.

A exposição é ampla. Qualquer sistema Linux num kernel baseado na versão 6.4 ou mais recente está afetado até ser corrigido, o que abrange computadores de secretária, servidores e telefones Android como o Pixel 10 em kernel 6.6. Os kernels da antiga linha 6.1 não estão afetados, porque a falha foi introduzida numa alteração de 2023 que chegou ao 6.4. Ainda não há exploração real reportada, mas com código funcional no GitHub a janela entre a publicação e o abuso é curta, e o epoll é usado em todo o lado, por isso não se pode simplesmente desligar.

A falha que uma auditoria de IA não apanhou

A lição mais nítida está em como a falha foi encontrada. Tanto Bad Epoll como a sua gémea, CVE-2026-43074, remontam à mesma única alteração de 2023 ao código do epoll. Uma auditoria de código automatizada apanhou a primeira do par no início de 2026, e a sua correção chegou. Não apanhou Bad Epoll. Essa foi encontrada à moda antiga, por uma pessoa: Jaeyoung Chung, da Universidade Nacional de Seul, reportou-a ao kernelCTF da Google como submissão de dia zero a 6 de julho de 2026, com um exploit fiável o suficiente para ser descrito como quase certo.

Leia isso com cuidado antes de concluir que a IA fechou a caça às falhas do kernel. A revisão automática é de facto útil e retirou da árvore uma falha de root viva. Mas um único commit arriscado produziu duas falhas exploráveis, a passagem automática levou uma e deixou a outra, e a que ficou era a que dá root. A revisão com IA sobe a base; não torna a aplicação de correções um passo opcional, e não significa que um commit que ela abençoou esteja limpo.

O que corrigir esta semana

A correção está no kernel mainline desde 24 de abril, como commit upstream a6dc643c6931, mas isso não é o mesmo que a correção chegar às suas máquinas. Muitas distribuições ainda não a retroportaram, por isso o risco real vive na distância entre corrigido em mainline e corrigido na frota. Aplique a última atualização de kernel da sua distribuição assim que sair, e no Pixel 10 e noutros aparelhos em kernel 6.6 a atualização de segurança da Google quando estiver disponível.

Dê prioridade por quem pode iniciar sessão. O perigo de uma falha local para root é maior onde utilizadores não fiáveis ou numerosos partilham um host: alojamento partilhado, executores de integração contínua, contentores multi-inquilino e máquinas de programação onde uma única conta comprometida não deve tornar-se a máquina inteira. Verifique a sua versão de kernel, trate como exposto tudo o que esteja em 6.4 ou posterior até ser corrigido, e use isto como aviso para rever outras correções nascidas da mesma alteração de epoll de 2023.