Bad Epoll: a falha de uso-after-free que poderia escalar privilégios ao root em Linux, Android e navegadores

A última falha do kernel do Linux apodada Bad Epoll (CVE-2026-46242) Lembre-se de que os erros de privilégios em código crítico podem aparecer em qualquer momento e ser extremamente perigosos: permite a um usuário normal sem privilégios escalar o root em máquinas Linux de desktop, servidores e Android, e já existe um adesivo disponível.

Bad Epoll é ocultado no subsistema epoll, a infraestrutura que usam servidores, serviços de rede e navegadores para monitorar muitas conexões simultâneas. Epoll não é uma característica dispensável, então não há uma “palanca” para desligar e evitar o risco: a única saída é patchar o kernel. A falha é um clássico da categoria use-after-free: dois caminhos do kernel tentam libertar e escrever sobre o mesmo objeto ao mesmo tempo, o que permite corromper memória do kernel e, com técnicas de exploração, elevar privilégios.

O que torna esta vulnerabilidade especialmente interessante para os técnicos é a sua natureza de carreira: a janela onde ocorre a colisão é microscópica, da ordem de algumas instruções. Isso significa que uma tentativa aleatória raramente funciona. O pesquisador Jaeyoung Chung, que descobriu o erro e construiu um exploit funcional, descreve como ampliou essa janela e acrescentou reintentos sem causar cuelgues, conseguindo escalados a root com sucesso em torno de 99% em seus testes.

Há outros fatores que aumentam o risco real: segundo Chung, Bad Epoll pode ser ativada desde o sandbox do renderer do Chrome, um ambiente que normalmente neutraliza muitos erros de kernel, e também afeta o Android, o que nem sempre ocorre com falhas de privilégios. Felizmente, até à data, não há evidência pública de exploração na natureza: não figura no catálogo de vulnerabilidades exploradas por atores conhecidos, mas isso não reduz a urgência do adesivo.

A correção chegou em upstream e está identificada pelo commit a6dc643c6931. A recomendação prática é aplicar esse commit ou instalar o backport que publica sua distribuição enquanto estiver disponível. Tenha em conta que os ramos do kernel 6.4 e posteriores estão afetados salvo que já recebessem esta correção; as séries 6.1 mais antigas, e, portanto, alguns telefones baseados em 6.1, não estão porque a mudança vulnerável apareceu em 6.4.

Do ponto de vista defensivo, não confie apenas em detectores em tempo de execução como KASAN para ser salvo: a memória corrupta que gera Bad Epoll costuma passar sem ativar KASAN uma vez que a falha relacionada anterior foi corrigida, pelo que a ausência de alertas não implica ausência de risco. A documentação do KASAN pode ajudar a entender os seus limites: Documentação do KASAN.

Para administradores e responsáveis pela segurança, a lista de ações recomendadas é clara: priorizar a aplicação do adesivo em servidores expostos e em imagens de contêiner, coordenar com fornecedores e fabricantes de Android para receber adesivos em dispositivos, e atualizar navegadores e sandbox que possam ser vetores de entrega. O catálogo de CISA sobre vulnerabilidades exploradas é um bom ponto de referência para priorização geral: CISA Known Exploited Vulnerabilities.

Bad Epoll também é útil como caso de estudo sobre a contribuição da inteligência artificial para a segurança do software. Um modelo avançado de Anthropic, Mythos, tinha detectado e ajudado a corrigir uma vulnerabilidade irmã na mesma zona do código, mas passou por alta esta. O próprio Chung sugere duas razões plausível: a janela de tempo é tão estreita que é difícil visualizar apenas a partir do código, e o erro produz pouca evidência em tempo de execução após o primeiro adesivo, o que complica sua identificação. A lição prática é que a IA já pode acelerar a busca de falhas, mas não substitui a inspeção humana e a verificação experimental, em particular para condições de carreira sutis.

Finalmente, para equipes de resposta e QA é crucial implantar testes reprodutíveis e exercícios de hardening: validar atualizações em ambientes que reproduzem o comportamento de carga, instrumentar builds com sanitizadores quando possível, e restringir a execução de código não confiável em ambientes que possam alcançar syscalls sensíveis. Os bugs de corrida continuam a ser os mais difíceis de encontrar e corrigir corretamente: Bad Epoll demonstra que até mesmo um adesivo inicial pode ficar curto e que a detecção humana continua a ser determinante para fechar o fosso entre “encontrado” e “corregido”.