GhostLock: la vulnerabilidad del kernel Linux que permite escapar de contenedores

Un nuevo fallo de alta gravedad en el kernel de Linux, bautizado como GhostLock (CVE-2026-43499), pone en alerta a administradores de servidores y plataformas de contenedores. La vulnerabilidad, presente desde el kernel 2.6.39 de 2011, permite a un atacante local sin privilegios escalar a root y, en ciertos escenarios, escapar del contenedor hacia el host.

El problema radica en el subsistema de bloqueos rtmutex, específicamente en la función remove_waiter() de kernel/locking/rtmutex.c. Durante el manejo de futex con herencia de prioridad, en casos de interbloqueo, el kernel podía limpiar la información de un proceso equivocado, dejando un puntero a memoria de pila ya liberada. Esto genera una condición use-after-free que, al controlarse, permite corrupción de memoria del kernel y elevación de privilegios.

Red Hat lo clasifica como de impacto “Important”, con un puntaje CVSS de 7.8. No se trata de un exploit remoto: el atacante necesita ejecutar código en el sistema, algo común en entornos multiusuario, CI/CD o plataformas de contenedores donde se corre software de terceros.

Uno de los riesgos más graves es el escape de contenedor. Como el aislamiento depende del kernel del host, un proceso comprometido dentro de un contenedor (Docker, Podman, Kubernetes, LXC) puede usar GhostLock para romper esa barrera y ganar control sobre el sistema completo. Esto afecta especialmente a servidores compartidos y entornos cloud donde múltiples cargas de trabajo comparten el mismo kernel.

La corrección llegó al kernel principal en la versión 7.1 mediante el commit 3bfdc63936dd, que simplemente cambia current por waiter->task en la función afectada. Además, el parche fue retroportado a las ramas LTS: 6.18.27, 6.12.86, 6.6.140, 6.1.175, 5.15 y 5.10, entre otras.

Importante: no alcanza con mirar el número que devuelve uname -r. Las distribuciones aplican backports de seguridad, por lo que un kernel 6.6 puede estar corregido mientras que otro con número superior aún no. Hay que revisar los avisos oficiales de cada distribución.

AlmaLinux, por ejemplo, ya publicó kernels corregidos para las versiones 8, 9 y 10. Lo mismo ocurre con RHEL, Ubuntu, Debian, Fedora y Arch. La recomendación es actualizar los paquetes de kernel a través de los repositorios oficiales, reiniciar y verificar que se esté corriendo la versión parcheada.

No existe una mitigación sencilla sin actualizar. Desactivar user namespaces, aplicar seccomp o usar perfiles de AppArmor/SELinux más restrictivos no elimina el riesgo, porque el bug no depende de namespaces sin privilegios. La única solución real es correr un kernel con el parche aplicado.

GhostLock vuelve a demostrar que incluso código que lleva 15 años en producción puede esconder errores sutiles de sincronización. En un ecosistema donde los contenedores se usan masivamente, este tipo de fallas recuerdan que la superficie de ataque del kernel sigue siendo crítica.

Si administrás servidores o usás contenedores en producción, verificá hoy mismo el estado de tu kernel. Actualizar es rápido y, en este caso, puede evitar que un usuario sin privilegios termine siendo root en el host.