GhostLock y Bad Epoll: dos fallas críticas de root en el kernel Linux

Render editorial de un núcleo de sistema con engranajes y una grieta antigua por la que escapa un proceso hacia privilegios de root, con acentos ámbar de alerta
0 0 votos
Valora la Publicación

Investigadores de seguridad revelaron esta semana dos fallas críticas de escalada de privilegios en el kernel Linux: GhostLock (CVE-2026-43499), un bug de 15 años presente en el código de bloqueo desde 2011, y Bad Epoll (CVE-2026-46242), una falla más reciente en el subsistema epoll. Ambas permiten que un usuario común, sin permisos especiales, obtenga root.

Qué es GhostLock y por qué preocupa tanto

GhostLock (CVE-2026-43499) es un use-after-free en el código de herencia de prioridad de los futex del kernel, una pieza de la maquinaria de bloqueo intacta desde 2011. Un paso de limpieza se ejecuta en el momento equivocado, borra el registro de otra tarea y deja al kernel apuntando a memoria ya liberada y reutilizada.

Resultado: cualquier usuario logueado, sin configuración especial, puede escalar a root, y el bug también habilita escape de contenedores. Afecta a prácticamente todas las distribuciones mainstream desde 2011, y en Android es explotable combinado con fallas de Firefox.

Tiene CVSS 7.8 (alto), requiere acceso local y alcanzó 97% de confiabilidad en las pruebas de explotación. Lo encontró Nebula Security con VEGA, su herramienta de búsqueda de bugs basada en IA; Google pagó 92.337 dólares vía kernelCTF.

El parche llegó en abril de 2026 (commit 3bfdc63936dd), aunque esa corrección introdujo otro bug (CVE-2026-53166, un crash) que todavía se termina de resolver upstream.

Qué es Bad Epoll

Bad Epoll (CVE-2026-46242) es una falla distinta, en epoll (el mecanismo estándar de Linux para vigilar muchos archivos o conexiones a la vez). También es un use-after-free: dos partes del kernel intentan limpiar el mismo objeto interno al mismo tiempo, una libera la memoria mientras la otra todavía escribe en ella, y esa corrupción permite escalar de cuenta normal a root. Afecta kernels 6.4 en adelante sin parchear (los basados en 6.1, como los Pixel 8, no están expuestos porque el bug llegó con la 6.4). Impacta escritorios, servidores y Android, y puede dispararse desde el sandbox del renderer de Chrome.

Lo descubrió el investigador Jaeyoung Chung, quien lo reportó como zero-day a kernelCTF; no hay evidencia de explotación real por ahora. El fix está en el commit a6dc643c6931 y ya se distribuye en backports.

El ángulo de la IA: qué encontró y qué no encontró

Acá conviene ser precisos porque hay dos historias de IA que se prestan a confusión. La nota de Wired titulada «AI found a root bug in Linux that everyone missed for 15 years» se refiere a GhostLock: fue Nebula Security, con su herramienta VEGA, la que encontró ese bug de 2011. Es la IA del hallazgo de los 15 años, no la de Bad Epoll.

La otra historia corresponde a la cobertura de Bad Epoll: el modelo Mythos, de Anthropic, analizó el mismo código de epoll pero encontró un bug distinto (CVE-2026-43074), originado en un cambio de 2023 en esa sección. Mythos no halló Bad Epoll (CVE-2026-46242) —eso lo hizo el investigador humano Jaeyoung Chung— y ese bug tampoco tiene 15 años, sino unos tres.

Son tres hallazgos distintos: GhostLock (IA de Nebula Security, 2011, el de Wired), Bad Epoll (humano, 2023) y el bug adicional que Mythos detectó en epoll (IA de Anthropic, 2023, CVE-2026-43074). Conviene no mezclarlos.

Qué hacer

Para GhostLock, verificar que los kernels en producción tengan el commit 3bfdc63936dd (o el parche de la distro) y seguir la corrección pendiente por el crash de CVE-2026-53166. Para Bad Epoll, aplicar el commit a6dc643c6931 o el backport correspondiente en kernels 6.4+, incluyendo Android. En ambos casos, al ser escaladas de privilegio local, conviene revisar también el aislamiento de contenedores y sandboxes que dependan del kernel host.

Auditar el kernel, un pendiente que no puede esperar

Para quienes administran infraestructura Linux en la comunidad MUG, esta semana recuerda que «estable» no es sinónimo de «seguro»: GhostLock estuvo ahí desde 2011 sin que nadie lo viera. Vale la pena revisar el parcheo del kernel en servidores y contenedores de producción, sin asumir que una versión LTS está libre de sorpresas.

¿Tu organización ya tiene un proceso para trackear CVEs de kernel además de los parches de aplicación?

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x