Qué hace Bad Epoll y quién está expuesto

Bad Epoll es una condición de carrera de uso después de liberar en epoll, la utilidad estándar de Linux que permite a un programa vigilar muchos archivos y conexiones a la vez. Cuando dos listas eventpoll se vigilan mutuamente y se cierran en el mismo instante, una libera un objeto interno mientras la otra aún escribe en él, y esa breve colisión permite a un proceso sin privilegios corromper memoria del kernel y llegar a root. El exploit público filtra memoria del kernel, secuestra una llamada indirecta y construye una cadena orientada a retorno hasta una shell de root.

La exposición es amplia. Cualquier sistema Linux con un kernel basado en la versión 6.4 o posterior está afectado hasta que se parchee, lo que incluye equipos de escritorio, servidores y móviles Android como el Pixel 10 con kernel 6.6. Los kernels de la antigua línea 6.1 no están afectados, porque el fallo se introdujo en un cambio de 2023 que llegó a 6.4. Aún no hay explotación real reportada, pero con código funcional en GitHub la ventana entre la publicación y el abuso es corta, y epoll se usa en todas partes, así que no se puede apagar sin más.

El fallo que una auditoría de IA no detectó

La lección más aguda está en cómo se halló el fallo. Tanto Bad Epoll como su gemelo, CVE-2026-43074, se remontan a la misma edición única de 2023 del código de epoll. Una auditoría de código automatizada detectó el primero del par a principios de 2026, y su parche llegó. No detectó Bad Epoll. Ese se halló al modo antiguo, por una persona: Jaeyoung Chung, de la Universidad Nacional de Seúl, lo reportó al kernelCTF de Google como envío de día cero el 6 de julio de 2026, con un exploit lo bastante fiable como para describirse como casi seguro.

Lea eso con cuidado antes de concluir que la IA ha cerrado la caza de fallos del kernel. La revisión automática es de verdad útil y quitó del árbol un fallo de root vivo. Pero un solo commit arriesgado produjo dos fallos explotables, la pasada automática tomó uno y dejó el otro, y el que dejó era el que da root. La revisión con IA sube la base; no convierte el parcheo en un paso opcional, y no significa que un commit que ha bendecido esté limpio.

Qué parchear esta semana

El parche está en el kernel mainline desde el 24 de abril, como commit upstream a6dc643c6931, pero eso no es lo mismo que el parche llegando a sus máquinas. Muchas distribuciones aún no lo han retroportado, así que el riesgo real vive en la brecha entre corregido en mainline y parcheado en la flota. Aplique la última actualización de kernel de su distribución en cuanto salga, y en el Pixel 10 y otros equipos con kernel 6.6 la actualización de seguridad de Google cuando esté disponible.

Priorice por quién puede iniciar sesión. El peligro de un fallo local a root es mayor donde usuarios no confiables o numerosos comparten un host: alojamiento compartido, agentes de integración continua, contenedores multiinquilino y equipos de desarrollo donde una sola cuenta comprometida no debería convertirse en toda la máquina. Compruebe su versión de kernel, trate como expuesto todo lo que esté en 6.4 o posterior hasta parchear, y use esto como recordatorio para revisar otros arreglos surgidos del mismo cambio de epoll de 2023.

Leer a continuación: Un fallo de root en Linux golpea servidores y Android  |  Este malware borra primero tus copias de seguridad