Bad Epoll: el fallo de uso-after-free que podría escalar privilegios a root en Linux, Android y navegadores

La última falla del kernel de Linux apodada Bad Epoll (CVE-2026-46242) vuelve a recordar que los errores de privilegios en código crítico pueden aparecer en cualquier momento y ser extremadamente peligrosos: permite a un usuario normal sin privilegios escalar a root en máquinas Linux de escritorio, servidores y en Android, y ya existe un parche disponible.

Bad Epoll se oculta en el subsistema epoll, la infraestructura que usan servidores, servicios de red y navegadores para vigilar muchas conexiones simultáneas. Epoll no es una característica prescindible, así que no hay una “palanca” para apagarla y evitar el riesgo: la única salida es parchear el kernel. El fallo es un clásico de la categoría use-after-free: dos caminos del kernel intentan liberar y escribir sobre el mismo objeto al mismo tiempo, lo que permite corromper memoria del kernel y, con técnicas de explotación, elevar privilegios.

Lo que hace esta vulnerabilidad especialmente interesante para los técnicos es su naturaleza de carrera: la ventana donde ocurre la colisión es microscópica, del orden de unas pocas instrucciones. Eso significa que un intento aleatorio rara vez funciona. El investigador Jaeyoung Chung, que descubrió el error y construyó un exploit funcional, describe cómo amplió esa ventana y añadió reintentos sin causar cuelgues, logrando escalados a root con éxito en torno al 99% en sus pruebas.

Hay otros factores que aumentan el riesgo real: según Chung, Bad Epoll puede ser activada desde el sandbox del renderer de Chrome, un entorno que normalmente neutraliza muchos errores de kernel, y además afecta a Android, lo que no siempre ocurre con fallos de privilegios. Afortunadamente, hasta la fecha no hay evidencia pública de explotación en la naturaleza: no figura en el catálogo de vulnerabilidades explotadas por actores conocidos, pero eso no reduce la urgencia del parcheo.

La corrección llegó en upstream y está identificada por el commit a6dc643c6931. La recomendación práctica es aplicar ese commit o instalar el backport que publique tu distribución en cuanto esté disponible. Ten en cuenta que las ramas del kernel 6.4 y posteriores están afectadas salvo que ya recibieran esta corrección; las series 6.1 más antiguas, y por tanto algunos teléfonos basados en 6.1, no lo están porque el cambio vulnerable apareció en 6.4.

Desde el punto de vista defensivo, no confíes únicamente en detectores en tiempo de ejecución como KASAN para estar a salvo: la memoria corrupta que genera Bad Epoll suele pasar sin activar KASAN una vez que se parcheó el fallo relacionado anterior, por lo que la ausencia de alertas no implica ausencia de riesgo. La documentación de KASAN puede ayudar a entender sus límites: documentación de KASAN.

Para administradores y responsables de seguridad la lista de acciones recomendadas es clara: priorizar la aplicación del parche en servidores expuestos y en imágenes de contenedor, coordinar con proveedores y fabricantes de Android para recibir parches en dispositivos, y actualizar navegadores y sandbox que puedan ser vectores de entrega. El catálogo de CISA sobre vulnerabilidades explotadas es un buen punto de referencia para priorización general: CISA Known Exploited Vulnerabilities.

Bad Epoll también es útil como caso de estudio sobre la contribución de la inteligencia artificial a la seguridad del software. Un modelo avanzado de Anthropic, Mythos, había detectado y ayudado a parchear una vulnerabilidad hermana en la misma zona del código, pero pasó por alto ésta. El propio Chung sugiere dos razones plausibles: la ventana de tiempo es tan estrecha que es difícil visualizarla solo a partir del código, y el error produce poca evidencia en tiempo de ejecución tras el primer parche, lo que complica su identificación. La lección práctica es que la IA ya puede acelerar la búsqueda de fallos, pero no sustituye la inspección humana y la verificación experimental—en particular para condiciones de carrera sutiles.

Finalmente, para equipos de respuesta y QA es crucial desplegar pruebas reproducibles y ejercicios de hardening: validar actualizaciones en entornos que reproduzcan el comportamiento de carga, instrumentar builds con sanitizadores cuando sea posible, y restringir la ejecución de código no confiable en entornos que puedan alcanzar syscalls sensibles. Los bugs de carrera siguen siendo de los más difíciles de encontrar y de corregir correctamente: Bad Epoll demuestra que incluso un parche inicial puede quedarse corto y que la detección humana sigue siendo determinante para cerrar la brecha entre “encontrado” y “corregido”.