GhostLock convierte un fallo de Futex de hace 15 años en un shell de root

La versión resumida

Ir a la versión completa ↓

Qué es: GhostLock (CVE-2026-43499) es una vulnerabilidad de tipo «use-after-free» en el código de herencia de prioridades de futex del núcleo de Linux, la función de bloqueo en la que se basa la biblioteca glibc PTHREAD_PRIO_INHERIT mutexes. Un paso de limpieza borra los registros del hilo equivocado, dejando un hilo activo que apunta a memoria ya liberada. Curiosamente, esa memoria se encuentra en el núcleo pila, y no en el montón, donde se encuentran la mayoría de esos errores. Ir a la versión completa →

Impacto: Escalada de privilegios locales a root. El exploit público de cadena completa de Nebula Security alcanza el nivel de root desde un proceso sin privilegios en unos cinco segundos, con una fiabilidad aproximada del 97 %. Hemos reproducido el desencadenante y el ataque DoS local en Debian 11/12/13, EL7 y EL10; se debe asumir que cualquier kernel afectado es vulnerable a la escalada a root, no solo a ataques DoS. Ir a la versión completa →

Gravedad: CVSS 7,8 (Alta). Vector local, complejidad baja, sin interacción del usuario y una cadena LPE pública altamente fiable en los objetivos compatibles. Red Hat la clasifica como «Importante». Ir a la versión completa →

A quiénes afecta: El único requisito previo es CONFIG_FUTEX_PI=y, activado por defecto en todas las distribuciones principales; no se necesitan capacidades especiales, espacios de nombres ni hardware específico. Se introdujo en Linux 2.6.39-rc1 (mayo de 2011), y el rango de versiones vulnerables se extiende hasta la v7.1-rc1, por lo que casi todos los núcleos en producción se ven afectados. Ir a la versión completa →

Falla relacionada: Un cambio posterior, 74e144274af3 (CVE-2026-53166), se revirtió posteriormente en el código fuente original debido a una regresión. Comprueba la cobertura de GhostLock a través de CVE-2026-43499 y la corrección principal 3bfdc63936dd. Ir a la versión completa →

Estado: Un «N-day», no un «zero-day». Notificado el 18 de abril, corregido en el código fuente el 20 de abril (3bfdc63936dd), y se aplicó retroactivamente el 4 de mayo, todo ello antes de que se hiciera público el 7 de julio. Ya se ha hecho público un exploit funcional y la vulnerabilidad ya ha aparecido en la prensa especializada en seguridad. Ir a la versión completa →

Hazlo ahora: No existe ninguna medida de mitigación en tiempo de ejecución que se aplique a todo el sistema; la característica vulnerable está integrada en la compilación y no se puede desactivar en un núcleo en ejecución. Aplica un núcleo corregido por el proveedor o un parche de KernelCare que no requiera reinicio. En los contenedores, un filtro seccomp que bloquee las operaciones futex PI elimina el desencadenante, aunque a costa de que dejen de funcionar las cargas de trabajo que utilicen esos bloqueos. Ir a la versión completa →

Hay dos razones que te llevarán a clasificar este ticket como de baja prioridad, y ambas son erróneas.

La primera es la antigüedad del código. GhostLock reside en una rutina de bloqueo que se lanzó en mayo de 2011. Un error que permaneció oculto durante quince años parece una curiosidad teórica, el tipo de hallazgo que se presenta en una conferencia pero que nunca llega a afectar a un servidor de producción. Esa interpretación resulta cómoda, pero es errónea. Se puede acceder al error desde un proceso sin privilegios en un kernel predeterminado, y existe un exploit público de cadena completa que lo convierte en un shell de root en cuestión de segundos.

El segundo es el término «futex». Un futex (mutex rápido del espacio de usuario) es el componente básico del núcleo que utilizan bibliotecas como glibc para implementar bloqueos entre subprocesos. Suena a algo muy técnico con lo que la mayoría de las aplicaciones nunca entran en contacto directamente, y eso es cierto, pero la característica que está en el centro de este error, el bloqueo con herencia de prioridad, no es algo minoritario. CONFIG_FUTEX_PI está habilitado por defecto en todas las distribuciones principales; glibc lo utiliza para PTHREAD_PRIO_INHERIT mutexes, y se puede acceder a la ruta vulnerable sin necesidad de capacidades, espacios de nombres ni hardware especial. Si tu núcleo se encuentra dentro del rango afectado y se ha compilado con la configuración predeterminada, la vulnerabilidad está presente.

GhostLock es la segunda entrega de la serie de investigación «IonStack» de Nebula Security, dada a conocer públicamente el 7 de julio de 2026 por el equipo al que se atribuye el nombre de VEGA, con un informe completo, una entrada en la lista de fallos y una prueba de concepto pública de cadena completa. El 30 de junio obtuvo una recompensa de Google kernelCTF de 92 337 dólares. Nos hicimos eco de ello la mañana del 8 de julio, y un ingeniero de KernelCare comenzó a reproducir el fallo en distintas distribuciones ese mismo día.

Antes de entrar en detalles, hay que tener claro lo siguiente: se trata de un error de la línea principal, no de una peculiaridad de la distribución. Cualquier kernel, desde la versión 2.6.39-rc1 hasta la 7.1-rc1, compilado con futex PI contiene el código vulnerable. El exploit publicado es específico para cada sistema en sus etapas finales, pero el defecto subyacente es prácticamente universal.

Cómo funciona GhostLock

Empieza por la parte del núcleo implicada. Cuando un hilo espera en un bloqueo de herencia de prioridad, el núcleo realiza un seguimiento de esa relación en un pequeño registro denominado «waiter» y anota en el hilo en espera en qué bloqueo se encuentra bloqueado (un campo denominado pi_blocked_on). Es importante corregir ese registro, ya que si un hilo se retira y sigue marcado como bloqueado en un bloqueo que ya no existe, el núcleo mantiene un puntero a la nada.

La rutina de limpieza, remove_waiter(), se escribió para el caso más sencillo: un hilo que libera su propia espera. Se parte de la base de que el hilo que realiza la liberación, al que el núcleo denomina current, es el mismo hilo que estaba en espera. Una operación más avanzada denominada «requeue-PI» rompe esa suposición. «Requeue-PI» traslada un hilo en espera de un bloqueo a otro (así es como se implementan de forma eficiente las variables de condición), lo que significa que el hilo que ejecuta la limpieza es el que realiza el traslado, y no el que estaba en espera.

Aquí está el error. Cuando el núcleo detecta que volver a poner en cola provocaría un interbloqueo (un ciclo en el que cada hilo espera al siguiente) y se sale con un error, la ruta de reversión llama a remove_waiter(), y remove_waiter() borra current->pi_blocked_on, el de mudanzas registro, en lugar del del camarero real. El hilo de espera nunca se libera. Cuando vuelve al espacio de usuario, su pi_blocked_on sigue apuntando a su propio marco de pila, que el núcleo ya ha recuperado para otros fines. Ese puntero colgante que apunta a la memoria de pila liberada es lo que se conoce como «uso después de la liberación».

A grandes rasgos, el exploit se basa en ello de la siguiente manera:

[Unprivileged process, three threads/futexes]
│  stage a deadlock cycle so the kernel takes the buggy rollback path
▼
[remove_waiter() clears the wrong thread's record → a live thread points into its own freed stack frame]
│
▼
[Reclaim that freed frame with attacker-controlled data → forge a fake waiter record]
│
▼
[Trigger the cleanup again → write one attacker-chosen pointer into a kernel network table]
│
▼
[Point that table entry at attacker code → send one IPv6 UDP packet to run it]
▼
[Flip a system setting (core_pattern) so a crash handler runs as root → root shell]

A modo de explicación para los lectores que lo deseen: el atacante provoca el interbloqueo con tres subprocesos y futexes utilizando el FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, y FUTEX_CMP_REQUEUE_PI operaciones, lo que obliga a la -EDEADLK (interbloqueo) y la reversión defectuosa. A continuación, recuperan el marco de pila liberado utilizando PR_SET_MM_MAP, una llamada de control de procesos que permite a un programa establecer campos que el núcleo copia en su propia pila, llenando esa memoria con un valor falsificado rt_mutex_waiter registro. La limpieza del árbol de espera del núcleo se convierte entonces en una única escritura controlada en un puntero, dirigida a inet6_protos[IPPROTO_UDP], la entrada de la tabla que indica al núcleo qué función gestiona los paquetes UDP IPv6 entrantes. El atacante redirige esa entrada hacia una instrucción «pivot» situada en una dirección fija y predecible (el área de entrada de la CPU, una región específica de cada CPU que siempre se encuentra en una ubicación conocida) y, a continuación, envía un paquete UDP IPv6 para invocarla. Esto cede el control a una cadena de programación orientada al retorno (que une fragmentos de código existentes del núcleo para ejecutar lógica arbitraria), y el paso final invierte los permisos en el core_pattern parámetro que controla qué programa se ejecuta cuando un proceso falla, de modo que el gestor de fallos del atacante se ejecuta como root.

Las funciones implicadas son remove_waiter(), rt_mutex_start_proxy_lock(), y rt_mutex_adjust_prio_chain() en kernel/locking/rtmutex.c. El fallo consiste en un «use-after-free» en la pila del núcleo que da lugar a una escalada de privilegios locales. Merece la pena detenerse un momento en el término «pila»: la mayoría de los fallos de «use-after-free» explotables corrompen objetos del montón, donde la disposición es relativamente fácil de manipular. Recuperar un objeto específico liberado pila Los marcos con contenido controlado son más difíciles de conseguir y menos habituales, lo que explica en parte por qué este fallo es tan interesante y, en manos del investigador, sigue siendo fiable.

Qué cambia con la corrección de Upstream

La solución principal consiste en una corrección de una sola línea. Antes del parche, la reversión del interbloqueo borraba el registro de bloqueo del hilo equivocado. Después de aplicarlo, remove_waiter() borra waiter->task->pi_blocked_on (el registro del camarero de verdad) en lugar de current->pi_blocked_on (la del programa que realiza la operación), por lo que la operación de liberación ya no deja ningún hilo activo que apunte a memoria de pila liberada.

Desde un punto de vista conceptual:

Before:  deadlock rollback → clear the mover's record → real waiter left pointing at freed memory → use-after-free
After:   deadlock rollback → clear the real waiter's record → nothing left dangling

La confirmación anterior es 3bfdc63936dd («rtmutex: Utilizar waiter::task en lugar de current en remove_waiter()»). Un cambio posterior, 74e144274af3, se registró por separado como CVE-2026-53166, pero posteriormente se revirtió en el código fuente original debido a una regresión. No debe considerarse como una segunda corrección necesaria para GhostLock.

Dado que se trata de un pequeño cambio aislado en la ruta de bloqueo, que no afecta a la estructura de ningún dato, es un buen candidato a parche limpio que no requiere reinicio en todas las familias de núcleos.

¿A quién afecta?

GhostLock afecta a los sistemas Linux compilados con CONFIG_FUTEX_PI=y, que es la configuración predeterminada de todas las distribuciones principales. El código vulnerable se introdujo en la confirmación 8161239a8bcc en Linux 2.6.39-rc1 (mayo de 2011), y el rango afectado se extiende hasta la versión v7.1-rc1. En la práctica, el impacto es prácticamente universal: cualquier núcleo de ese rango compilado con futex PI.

El equipo de KernelCare ha confirmado los efectos, el desencadenante y la reproducción del ataque DoS local mediante el PoC público:

• Debian 13 (ya solucionado, véase más abajo)
• Debian 12, vulnerable y aún sin solucionar
• Debian 11, vulnerable y sin errata todavía
• Enterprise Linux 7: se ha reproducido el ataque DoS
• Enterprise Linux 10: se ha reproducido el ataque DoS

Acceso root en toda la cadena: el investigador demostró públicamente que se podía obtener acceso root con una fiabilidad aproximada del 97 %. El componente de explotación utilizado como arma es específico para cada objetivo y contiene desplazamientos de memoria propios de cada uno de ellos, integrados en su código fuente. Nuestra verificación en varias distribuciones puso a prueba el desencadenante y el «use-after-free», pero no el acceso root específico para cada objetivo en cada distribución. La hipótesis de trabajo más segura es que cualquier núcleo afectado puede ser explotado por un atacante motivado para obtener acceso root, y no solo es susceptible de sufrir un ataque de denegación de servicio (DoS).

Hay que prestar atención al panorama de Enterprise Linux. A fecha de 8 de julio, la página pública de CVE de Red Hat recoge todos los núcleos de RHEL (6, 7, 8, 9 y 10, incluido el de tiempo real kernel-rt) como «Afectado», con un nivel de gravedad de la amenaza «Importante», sin que se haya publicado aún ninguna errata. Esa página cambió a lo largo del día: a primera hora del 8 de julio indicaba que RHEL no era vulnerable, y cualquier interpretación inicial de que «EL no se veía afectado» se basaba en esa versión, ahora superada. Este es un caso en el que leer el aviso una sola vez y pasar de largo habría llevado a una conclusión errónea.

La corrección técnica de Red Hat ya se ha incorporado de forma discreta en CentOS Stream (la versión de vista previa continua de los próximos núcleos de RHEL). La corrección para Stream 9 se aplicó en kernel-5.14.0-716.el9 y se mostró vulnerable en kernel-5.14.0-699.el9. El canal 10 se ha solucionado en kernel-6.12.0-239.el10 y se mostró vulnerable en kernel-6.12.0-224.el10. Dado que CloudLinux 9 y 10 se basan en los núcleos de AlmaLinux y EL9/EL10, esa corrección de Stream se aplica a esas versiones, por lo que lo que hay que hacer en la práctica es comprobar en qué lado de la línea divisoria entre el núcleo corregido y el vulnerable se encuentra el núcleo general que estás utilizando actualmente. Los límites para EL7 y EL8 aún no se han confirmado.

Actúa ya

Se lo digo sin rodeos: no existe ninguna medida de mitigación en tiempo de ejecución clara, general y que abarque todo el sistema.

El único requisito previo para que se produzca el error es CONFIG_FUTEX_PI, y se trata de una opción de compilación sin opción de activación en tiempo de ejecución. Es necesaria para los mutexes de herencia de prioridad de glibc, por lo que no se puede desactivar en un núcleo de producción en funcionamiento sin que se vean afectados los programas del espacio de usuario que dependen de esos bloqueos. No hay ningún módulo que se pueda incluir en la lista negra ni ningún ajuste que se pueda modificar.

Eso nos deja las actualizaciones de seguridad y una medida específica para cada carga de trabajo.

Contenedores y cargas de trabajo en entornos aislados. Una política seccomp (la función de Linux que permite filtrar las llamadas al sistema que puede realizar un programa) que bloquea las operaciones de herencia de prioridad de futex, FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, y FUTEX_CMP_REQUEUE_PI, cierra el disparador. Un filtro eficaz debe abarcar también las variantes, el futex_time64 las llamadas al sistema y los números de llamadas al sistema específicos de cada arquitectura, además de FUTEX_LOCK_PI2 En los núcleos más recientes, o bien el bloqueo puede eludirse. El inconveniente es que esto provoca fallos en cualquier carga de trabajo que utilice mutexes con herencia de prioridad, por lo que conviene realizar pruebas antes de la implementación. Esta palanca es también lo que hace que el concepto de «escape del contenedor» sea una realidad: el código sin privilegios dentro de un contenedor llega al fallo, a menos que el entorno de ejecución ya filtre estas operaciones de futex.

En cualquier otro lugar. No existe ninguna medida de mitigación para todo el servidor, salvo aplicar la actualización del núcleo del proveedor o el parche de KernelCare que no requiere reinicio.

Momento decisivo. Si utilizas contenedores o entornos aislados y puedes tolerar la pérdida de los bloqueos de herencia de prioridad, implementa el filtro seccomp como medida provisional mientras programas la solución definitiva. Para los hosts de uso general, la única solución real es un núcleo corregido o un parche que no requiera reinicio, así que dale prioridad a estas opciones y aísla la ejecución local no confiable hasta que se aplique una de ellas. Da prioridad a las actualizaciones de Debian 13 y EL9 que ya están disponibles, junto con las versiones especializadas de Ubuntu 24.04, Proxmox VE 8 y AlmaLinux, y utiliza el canal «testing» cuando sea adecuado para Debian 12 y EL10 mientras esté pendiente su promoción al canal de producción.

Lista de verificación de medidas correctoras priorizadas

1. Registra esto como CVE-2026-43499 (GhostLock) y confirma que el kernel en ejecución o el parche «patchlivepatch» sin reinicio incluya la corrección principal, 3bfdc63936dd. El cambio posterior, registrado como CVE-2026-53166, se ha revertido en el código fuente original y no es necesario para confirmar la cobertura de GhostLock.
2. Trata cada kernel del rango comprendido entre 2.6.39-rc1 y 7.1-rc1 compilado con CONFIG_FUTEX_PI se considerará afectado hasta que se demuestre lo contrario.
3. Da prioridad a los servidores en los que el aislamiento local constituya el límite de seguridad: alojamiento compartido, nodos multitenant, ejecutores de CI y servidores de contenedores y de desarrollo que ejecuten código no fiable.
4. En el caso de Enterprise Linux, comprueba en qué lado de la línea divisoria entre el núcleo corregido y el vulnerable se encuentra cada host, en lugar de fiarte únicamente de lo que dice un único aviso. Stream 9 corregido en kernel-5.14.0-716.el9, Canal 10 fijado en kernel-6.12.0-239.el10; Los límites de EL7 y EL8 aún no se han confirmado.
5. Si no es posible aplicar el parche de inmediato y la carga de trabajo lo permite, aplica un filtro seccomp que bloquee las operaciones de herencia de prioridad de futex en contenedores y entornos aislados.
6. No desactives CONFIG_FUTEX_PI en un núcleo en ejecución; provoca un fallo en los mutexes de herencia de prioridad de glibc y no es una medida correctiva admitida.
7. Aplica ya las correcciones disponibles para las versiones especializadas de Debian 13, EL9, Ubuntu 24.04, Proxmox VE 8 y AlmaLinux, y utiliza el canal «testing» para Debian 12 y EL10, sin dejar de realizar un seguimiento de Debian 11, Amazon Linux 2023 y EL7 a medida que se vaya incorporando la cobertura.
8. Buscar core_pattern cambios, advertencias del núcleo relacionadas con «rtmutex-path» y aumentos inexplicables de privilegios, y considera que los hash de archivos limpios no constituyen pruebas suficientes sobre el host.
9. Aplica un kernel fijo del proveedor y reinicia el sistema, o utiliza el parche sin reinicio de KernelCare para el kernel que se esté ejecutando en ese momento, dando prioridad a los hosts que resulten más difíciles de reiniciar.

Detección

GhostLock no deja ninguna firma fiable en el disco. La corrupción se produce en la memoria del núcleo, y la acción final documentada cambia una configuración del núcleo en lugar de modificar archivos, por lo que las herramientas de integridad de archivos pueden permanecer intactas tras la explotación. Esto hace que la detección se base en el comportamiento. Las siguientes señales se derivan de la cadena de explotación publicada, y cada una de ellas es una pista, no una prueba:

• Cambios inesperados en /proc/sys/kernel/core_pattern, o a sus permisos, especialmente un controlador que ejecuta un programa externo en caso de fallo. La cadena pública termina abusando de core_pattern para obtener privilegios de root.
• Procesos sin privilegios que ejecutan bucles ajustados de operaciones de herencia de prioridad con futex (FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI) en varios subprocesos, lo que concuerda con forzar la ruta de interbloqueo.
• Errores o advertencias del núcleo en el código de rtmutex (mutex en tiempo real), en torno a remove_waiter(), rt_mutex_start_proxy_lock()o rt_mutex_adjust_prio_chain(), sin que se haya detectado ningún fallo de hardware relacionado.
• Uso de PR_SET_MM_MAP por procesos que no tienen ningún motivo legítimo para reescribir su propia estructura de memoria, en un momento cercano al anterior.
• Una cuenta o un servicio local que obtiene privilegios poco después de una ráfaga de inestabilidad en futex y rtmutex, sin que se haya producido ningún evento de «sudo» o de inicio de sesión que lo justifique.

Revisar los mensajes recientes del núcleo:

journalctl -k --since "24 hours ago" | grep -Ei 'rtmutex|pi_blocked|remove_waiter|BUG|WARNING'

La ausencia de estos mensajes no demuestra que un host esté actualizado o no haya sido comprometido. Un atacante astuto puede evitar activar una alerta, y es posible que simplemente aún no se haya explotado una vía de vulnerabilidad. Si durante el periodo de exposición se ejecutó código local no fiable o semiconfiable en un host afectado, se debe considerar que dicho host requiere un análisis más detallado —incluyendo la presencia de nuevas cuentas, cambios en la configuración de autenticación y servicios inesperados— en lugar de interpretar los hash de archivos limpios como prueba de seguridad.

Por qué es importante GhostLock

GhostLock supone una escalada de privilegios local, no una ejecución remota de código. Nadie puede obtener acceso root en tu servidor desde Internet solo con esto. Para los entornos en los que realmente se produce, eso supone un escaso consuelo.

El alojamiento compartido ejecuta el código de los clientes. Los ejecutores de CI ejecutan lo que les indique la última solicitud de incorporación de cambios. Los contenedores y los nodos de Kubernetes ejecutan cargas de trabajo con distintos niveles de confianza, y los servidores multitenant existen precisamente para mantener separados a los distintos usuarios. En todos estos casos, la escalada de privilegios locales es el incidente que todo el diseño pretende evitar. Convierte el código cuya ejecución estaba permitida en código que se ejecuta como root, algo que nunca debería haber ocurrido.

La razón por la que es fácil juzgar mal es la misma por la que resulta peligroso. Tres señales plausibles apuntan todas hacia lo «seguro» y todas inducen a error. La antigüedad del fallo parece propia de una pieza de museo, cuando en realidad es accesible en un núcleo predeterminado actual. La característica futex parece algo muy específico, cuando en realidad está compilada en prácticamente todas las distribuciones y la utilizan los bloqueos estándar de glibc. Y un aviso consultado una sola vez la mañana del 8 de julio podría haber indicado que RHEL no era vulnerable, horas antes de que esa misma página cambiara para indicar que todos los núcleos de RHEL se veían afectados. Si te fías de cualquiera de ellos, darás por resuelto un host vulnerable.

GhostLock es el tipo de fallo para el que existen los parches sin necesidad de reinicio. El cambio del desarrollador original está disponible, pero eso no protege a un sistema en funcionamiento: el proveedor tiene que adaptarlo, hay que instalar el paquete y el equipo tiene que arrancar con el nuevo núcleo. En entornos multitenant y flotas de contenedores, ese último paso puede prolongar un fallo conocido de «root local» durante semanas de exposición residual, y es precisamente en los hosts que corren mayor riesgo donde resulta más gravoso.

Este cambio es un buen candidato para un parche que no requiera reinicio: se trata de una corrección pequeña e independiente en la ruta de bloqueo, sin cambios en la estructura de los datos ni estado persistente que haya que conservar. KernelCare adapta la corrección principal de GhostLock, 3bfdc63936dd, al núcleo en ejecución. Nota: se trata de un error exclusivo del núcleo, sin ningún componente de biblioteca del espacio de usuario.

Estado de la versión de los parches en tiempo real (KernelCare) a fecha de 10 de julio de 2026, a las 17:00 UTC.

Noticias principales:

• Familia EL9: RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 9 LTS y AlmaLinux 9 FIPS 9.6
• Ubuntu 24.04
• Proxmox VE 8

Datos de prueba:

• Familia EL10: RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10
• Debian 12

Corregido y publicado por el proveedor:

• Debian 13

Pendiente o aún sin publicar:

• Amazon Linux 2023: ya está compilado, pero aún no se ha lanzado
• Debian 11: cobertura pendiente
• EL7: cobertura pendiente
• EL6: prioridad baja

La información sobre el parche de KernelCare hace referencia únicamente a CVE-2026-43499; el hecho de que CVE confirme que GhostLock está parcheado. El cambio posterior, registrado como CVE-2026-53166, se revirtió en el código fuente debido a una regresión y no es necesario para verificar la cobertura.

Aplícalo desde el feed de pruebas en cuanto haya una etiqueta K disponible:

kcarectl --update --prefix test

Aplicar desde el canal de producción una vez que se haya promocionado:

kcarectl --update

Comprueba la correspondencia de GhostLock con los CVE en lugar de fiarte de la fecha de compilación:

kcarectl --info | grep kpatch-build-time      # build dated 2026-07-08 or later
kcarectl --patch-info | grep 'CVE-2026-43499'

La fecha de compilación por sí sola no prueba nada, ya que un núcleo compilado después de mediados de abril no incluye automáticamente la corrección de GhostLock. Comprueba directamente la correspondencia con el CVE, la errata del proveedor, el código fuente o el estado del parche «rebootless-patch».

GhostLock convierte un error de bloqueo de hace quince años en una brecha en los límites de privilegios locales. Para las flotas que no pueden permitirse reinicios de emergencia, un parche que no requiere reinicio cierra esa brecha en el núcleo en ejecución sin agotar los nodos ni interrumpir las cargas de trabajo.

Consigue KernelCare hoy mismo →

Cronología

Referencias

• IonStack, parte II: GhostLock, Nebula Security, 7 de julio de 2026: https://nebusec.ai/research/ionstack-part-2/
• Entrada en la lista de errores, CVE-2026-43499: https://nebusec.ai/buglist/CVE-2026-43499
• Demostración pública de concepto, CyberMeowfia/IonStack/CVE-2026-43499: https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack/CVE-2026-43499
• Solución en la fase inicial 3bfdc63936dd («rtmutex: Utilizar waiter::task en lugar de current en remove_waiter()»): https://git.kernel.org/linus/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
• Se ha revertido el cambio de seguimiento 74e144274af3 (CVE-2026-53166; posteriormente revertido en el código original debido a una regresión): https://git.kernel.org/linus/74e144274af39935b0f410c0ee4d2b91c3730414
• Commit que introduce un error 8161239a8bcc («rtmutex: Simplificar el algoritmo PI y hacer que la tarea de mayor prioridad obtenga el bloqueo»), incluido en la versión v2.6.39-rc1
• Red Hat CVE-2026-43499 (kernel de RHEL 6-10 / kernel-rt figuran como afectados, gravedad: «Importante», BZ 2480453): https://access.redhat.com/security/cve/cve-2026-43499
• Correcciones silenciosas de CentOS Stream: cs9 4e5a31ae1fa9, cs10 7bba8926cefe
• Prensa: The Hacker News, «Una vulnerabilidad de GhostLock de hace 15 años permite obtener privilegios de root…»: https://thehackernews.com/2026/07/15-year-old-ghostlock-flaw-enables-root.html