El código de explotación de GhostLock se hace público para un fallo de root en Linux que permaneció oculto durante 15 años

Investigadores de Nebula Security han publicado un análisis técnico completo y el código de explotación funcional para GhostLock (CVE-2026-43499), una vulnerabilidad de use-after-free en el kernel de Linux que ha estado presente en todas las distribuciones principales desde 2011. El exploit logra la escalada de privilegios a root con un 97% de estabilidad y también puede utilizarse para el escape de contenedores, lo que lo convierte en uno de los exploits de escalada local de privilegios más fiables vistos en los últimos tiempos.

Un descuido de 15 años en el código de bloqueo del kernel

GhostLock reside en kernel/locking/rtmutex.c, específicamente en la función remove_waiter() que maneja la herencia de prioridad de los mutex en tiempo real (rtmutex). El bug se introdujo en Linux 2.6.39 en un commit de 2011 y permaneció sin parchear durante aproximadamente 15 años hasta abril de 2026.

El fallo se origina en un manejo sutilmente incorrecto de los punteros de tarea durante las operaciones de futex con herencia de prioridad (PI). Cuando un hilo se elimina de una lista de espera, la función borra incorrectamente el campo pi_blocked_on de la tarea que llama en lugar de la tarea correcta que se está eliminando. Un atacante sin privilegios puede desencadenar esta condición usando solo llamadas al sistema de threading estándar, obteniendo un puntero colgante del kernel a memoria de pila.

A partir de ahí, la cadena de ataque permite escribir un puntero a casi cualquier dirección del kernel y secuestrar una tabla de funciones para obtener control total del flujo, logrando finalmente una shell de root. El exploit requiere que CONFIG_FUTEX_PI esté habilitado, que es la configuración predeterminada en prácticamente todas las distribuciones de Linux.

Premiado con 92.337 dólares en el kernelCTF de Google

Nebula Security demostró GhostLock por primera vez en la competición kernelCTF de Google, donde recibieron una recompensa de 92.337 dólares por el exploit funcional. El informe de la Parte 2 del equipo, publicado el 7 de julio, proporciona una hoja de ruta completa de explotación que incluye las técnicas de diseño del montón utilizadas para alcanzar la tasa de éxito del 97% en versiones del kernel desde la 2.6.39 hasta la 7.1-rc1.

Según informó inicialmente Nebula Security, el rango vulnerable abarca la gran mayoría de los kernels distribuidos por las principales distribuciones en los últimos 15 años. Cualquier sistema que ejecute un kernel dentro de ese rango sin el conjunto de parches de abril de 2026 sigue siendo explotable por un usuario local.

El parche está disponible, pero muchos sistemas siguen desprotegidos

Los mantenedores del kernel de Linux lanzaron la corrección en abril de 2026 mediante commits al árbol estable, y las principales distribuciones han incluido el parche en sus actualizaciones más recientes del kernel LTS. Sin embargo, con el código de explotación público ahora disponible, cualquier sistema Linux sin parchear donde un usuario no confiado pueda iniciar sesión localmente corre un riesgo grave.

Los entornos de contenedores merecen especial atención: un breakout de contenedor a través de GhostLock le da al atacante acceso root en el host subyacente, eludiendo todo el aislamiento de contenedores. Los proveedores de nube que ejecutan entornos multiinquilino compartidos en kernels sin parchear deberían tratar esto como un problema P0.

Qué hacer ahora

Los administradores de sistemas deberían verificar inmediatamente la versión de su kernel y actualizar a la última versión LTS de su distribución si aún no lo han hecho. La corrección está en el árbol estable del kernel y se ha retroportado a todas las ramas LTS compatibles. Distribuciones como Ubuntu, Debian, Fedora, Red Hat Enterprise Linux y Alpine ya han publicado paquetes actualizados.

Ejecutar uname -r y compararlo con la versión del kernel parcheada de su distribución es la forma más rápida de comprobar la exposición. Hasta que se complete el parcheo, es recomendable restringir el acceso de usuarios locales y auditar los registros de auditoría en busca de intentos inusuales de escalada de privilegios.