GhostLock es el nombre con el que se ha dado a una vulnerabilidad de alta gravedad descubierta en el kernel de Linux. Identificada como CVE-2026-43499, afecta al subsistema de bloqueos rtmutex y puede provocar una condición de use-after-free en determinadas operaciones de futex con herencia de prioridad. Un atacante local sin privilegios podría aprovechar el fallo para elevar sus permisos hasta root y, en determinados escenarios, escapar de un contenedor hacia el sistema anfitrión.

El problema resulta especialmente relevante porque el código vulnerable lleva presente en Linux desde hace años y forma parte de una funcionalidad utilizada por los kernels de las principales distribuciones. La corrección ya llegó al kernel principal y también ha sido retroportada a las ramas mantenidas, pero los usuarios deben asegurarse de que su distribución haya instalado un kernel que incluya el parche. No basta con fijarse únicamente en el número de versión del kernel, ya que las distribuciones suelen incorporar correcciones de seguridad mediante backports.

GhostLock es una vulnerabilidad del subsistema rtmutex

El origen de GhostLock se encuentra en el código de gestión de mutex con herencia de prioridad del kernel Linux, concretamente en kernel/locking/rtmutex.c. Estos mecanismos forman parte de la infraestructura utilizada para coordinar la ejecución de diferentes hilos y evitar problemas de prioridad en determinadas cargas de trabajo.

La vulnerabilidad está relacionada con la función remove_waiter(). En determinadas circunstancias, el código podía limpiar la información asociada a un proceso equivocado durante la gestión de una espera de futex. El resultado era que un puntero podía quedar apuntando a una zona de memoria de la pila del kernel que ya había sido liberada.

Esta condición constituye un use-after-free: el kernel conserva una referencia a memoria cuyo tiempo de vida ya ha terminado y posteriormente puede intentar utilizarla como si siguiera siendo válida. Cuando un atacante consigue controlar las condiciones necesarias para reutilizar esa memoria, el fallo puede convertirse en una vulnerabilidad mucho más grave que un simple bloqueo del sistema.

El fallo afecta a los futex con herencia de prioridad

Para explotar GhostLock es necesario interactuar con la ruta de priority inheritance de los futex. Los futex son una de las primitivas fundamentales que Linux proporciona para sincronizar hilos entre espacio de usuario y kernel, y son utilizados indirectamente por numerosas aplicaciones y bibliotecas.

La ruta problemática entra en juego con operaciones de reencolado de futex que utilizan herencia de prioridad. En un escenario concreto de interbloqueo, el kernel tiene que deshacer parte de la operación y retirar un proceso de una estructura de espera. Es durante esta recuperación cuando se producía el comportamiento incorrecto de remove_waiter().

El error consistía, en esencia, en que la función utilizaba current cuando debía utilizar la tarea asociada al waiter. El parche que corrige el problema cambia precisamente este comportamiento para utilizar waiter->task.

Un atacante local podría conseguir privilegios de root

La consecuencia más importante de GhostLock es la posibilidad de escalada local de privilegios. Un usuario que ya disponga de una cuenta sin privilegios en un sistema vulnerable puede intentar desencadenar la condición de carrera y aprovechar posteriormente la corrupción de memoria del kernel.

Esto significa que GhostLock no es una vulnerabilidad que pueda explotarse simplemente enviando una página web maliciosa a un usuario remoto. El atacante necesita primero capacidad para ejecutar código en el sistema afectado. Sin embargo, ese requisito no hace que el problema sea trivial en entornos donde existen múltiples usuarios o donde se permite ejecutar software no confiable.

Red Hat clasifica el problema como de impacto Important y señala que puede permitir escalada de privilegios o una denegación de servicio. La valoración publicada para CVE-2026-43499 es CVSS 7.8, dentro de la categoría de vulnerabilidades de alta gravedad.

GhostLock también puede ser peligroso en contenedores

Uno de los aspectos que hacen especialmente interesante a GhostLock es su posible impacto sobre sistemas que utilizan contenedores. El código vulnerable puede ser alcanzado desde un proceso que se ejecuta dentro de un contenedor, por lo que un atacante que haya conseguido comprometer una carga de trabajo puede intentar utilizar el fallo contra el kernel del host.

En el escenario más grave, esto podría convertir una vulnerabilidad aparentemente local en un escape de contenedor. El aislamiento proporcionado por el contenedor depende en última instancia del kernel del sistema anfitrión, por lo que un fallo explotable en el kernel puede romper esa frontera.

Esto resulta especialmente importante en servidores multiusuario, plataformas de contenedores, servidores de integración continua y otras infraestructuras donde código de diferentes usuarios o aplicaciones comparte el mismo kernel. Red Hat y otros avisos de seguridad recomiendan prestar especial atención a estos entornos.

GhostLock llevaba años en el kernel

Una de las características más llamativas de GhostLock es la antigüedad del código que contiene el error. El problema se introdujo con un cambio realizado en Linux 2.6.39, publicado en 2011, y permaneció en el código durante aproximadamente quince años antes de ser corregido.

El fallo no significa que todas las instalaciones de Linux de esos años hayan estado explotadas activamente durante todo ese tiempo. Lo que demuestra es que una pieza de código utilizada durante mucho tiempo puede contener errores sutiles que solo aparecen cuando se combinan determinadas condiciones de sincronización.

Este tipo de vulnerabilidades son especialmente difíciles de detectar porque no dependen de una operación sencilla como acceder a un archivo o enviar una petición de red. En este caso intervienen varios hilos, futex, herencia de prioridad y una ruta de recuperación ante un interbloqueo.

Linux 7.1 ya incorpora la corrección

La corrección de CVE-2026-43499 llegó al kernel principal como parte de Linux 7.1. El cambio, identificado mediante el commit 3bfdc63936dd, modifica remove_waiter() para utilizar la tarea perteneciente al elemento que se está retirando en lugar de la tarea actualmente ejecutándose.

La corrección también ha sido retroportada a diferentes ramas estables de Linux. Por ello, no es necesario utilizar Linux 7.1 o una versión posterior para estar protegido. Existen versiones corregidas de las ramas LTS, entre ellas 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10.

En otras palabras, un sistema con un kernel antiguo puede estar completamente protegido si su distribución ha aplicado correctamente el backport. Por este motivo, comprobar únicamente el número que devuelve uname -r puede no ser suficiente para determinar el estado de seguridad en distribuciones que mantienen sus propios kernels.

Las distribuciones han tenido que aplicar sus propios parches

La corrección upstream no llega necesariamente al usuario al mismo tiempo que se publica en kernel.org. Las distribuciones Linux mantienen sus propios paquetes de kernel y suelen incorporar correcciones de seguridad en las ramas que ofrecen soporte.

Por ejemplo, AlmaLinux publicó kernels corregidos para sus versiones 8, 9 y 10 poco después de la divulgación de GhostLock. La distribución especificó versiones concretas de sus paquetes de kernel que contienen la corrección y recomendó actualizar y reiniciar el sistema para cargar el nuevo kernel.

La situación es similar en otras distribuciones empresariales y comunitarias. Por eso, la recomendación general es utilizar los canales oficiales de actualización de cada distribución y comprobar sus respectivos avisos de seguridad, en lugar de asumir que un kernel concreto es vulnerable o seguro únicamente por su versión base.

No existe una mitigación sencilla que sustituya al parche

Otro aspecto importante de GhostLock es que no existe una medida sencilla que permita desactivar la funcionalidad vulnerable sin actualizar el kernel. El problema se encuentra en código genérico del subsistema de locking y en una ruta de futex que forma parte de las capacidades normales del kernel.

Por ello, desactivar determinados mecanismos de namespaces o aplicar restricciones habituales para contener procesos no constituye una solución equivalente al parche. En particular, la información disponible sobre GhostLock indica que no depende de los user namespaces sin privilegios, por lo que endurecer esa característica no elimina la vulnerabilidad.

En servidores donde no sea posible actualizar inmediatamente, reducir el acceso de usuarios no confiables puede servir como medida de defensa en profundidad, pero no elimina el fallo. La solución real consiste en ejecutar un kernel que contenga la corrección.

Cómo comprobar si el kernel está actualizado

Los usuarios pueden consultar la versión del kernel actualmente en ejecución con el comando uname -r. Sin embargo, para determinar si GhostLock está corregido hay que comparar ese resultado con el estado de seguridad publicado por la distribución utilizada.

En el kernel upstream, la corrección está presente desde Linux 7.1. En las ramas mantenidas existen versiones anteriores que también incluyen el parche, pero los números exactos varían según la rama y la distribución. Por ejemplo, el seguimiento de la vulnerabilidad identifica Linux 6.18.27, 6.12.86, 6.6.140 y 6.1.175 como versiones upstream corregidas, entre otras.

Por tanto, si el equipo utiliza Ubuntu, Debian, Fedora, Arch Linux, RHEL, AlmaLinux o cualquier otra distribución, lo adecuado es instalar las últimas actualizaciones de seguridad disponibles para esa distribución y reiniciar si se ha actualizado el kernel.

GhostLock demuestra la importancia de mantener actualizado el kernel

GhostLock es un buen ejemplo de cómo una vulnerabilidad puede permanecer durante años en una parte extremadamente compleja del kernel Linux sin que su impacto sea evidente hasta que alguien encuentra una forma de alcanzar la ruta problemática. En este caso, un error aparentemente pequeño en la gestión de un proceso que espera un mutex puede terminar proporcionando una vía para corromper memoria del kernel.

El problema es especialmente relevante en servidores multiusuario y plataformas de contenedores, donde un atacante puede disponer de un entorno desde el que ejecutar código sin tener inicialmente privilegios sobre el sistema anfitrión. La posibilidad de convertir esa posición en privilegios de root o en un escape del contenedor eleva considerablemente la importancia de aplicar el parche.

La buena noticia es que GhostLock ya está corregido en el kernel Linux principal y las correcciones han sido retroportadas a las ramas mantenidas. Los usuarios no necesitan cambiar de distribución ni instalar necesariamente un kernel de desarrollo: deben asegurarse de que su distribución haya publicado el paquete de kernel corregido y que el sistema esté ejecutándolo.

Artículo original