GhostLock: una vulnerabilidad de tipo stack-UAF que estuvo oculta por más de 15 años en el kernel de Linux
Una vulnerabilidad crítica en el kernel de Linux, identificada como CVE-2026-43499 y apodada GhostLock, permaneció presente en la mayoría de distribuciones Linux por más de 15 años antes de ser corregida en 2026. La falla permite que un atacante local sin privilegios obtenga privilegios de root y escape de contenedores al aprovechar un error en el manejo de bloqueos en el mecanismo de futex con herencia de prioridad (rtmutex / futex PI). Acorde al análisis de Nebula Security, el exploit desarrollado consiguió una tasa de éxito reportada del 97% en sistemas vulnerables.
El problema se introdujo en la versión 2.6.39 del kernel en 2011 y se mantuvo hasta que se aplicó la corrección en Linux 7.1. La raíz del fallo es una operación de limpieza incorrecta en el kernel que mantiene una referencia suspendida a la memoria en la pila de un hilo después de que esa memoria deja de ser válida. Un atacante local puede reclamar esa región de memoria con datos controlados, lo que permite redirigir la ejecución en el espacio del kernel y obtener control total del sistema. Aunque la explotación publicada usa técnicas avanzadas para evadir protecciones modernas del kernel, la causa subyacente es un error lógico derivado de la reutilización de una función en un camino de ejecución distinto al original.
GhostLock no requiere privilegios elevados, namespaces especiales ni configuraciones inusuales del kernel; basta con que el kernel haya sido compilado con CONFIG_FUTEX_PI habilitado (valor por defecto en muchas construcciones generales). El fallo fue reportado al equipo de seguridad del kernel el 18 de abril de 2026, con parches propuestos y posteriores integraciones a ramas estables durante mayo. La corrección garantiza limpiar el estado para la tarea correcta y eliminar el puntero "suspendido". Mientras que medidas de hardening como RANDOMIZE_KSTACK_OFFSET reducen la fiabilidad del exploit publicado, la mitigación más completa y recomendada es actualizar a un kernel parcheado. Sin embargo, actualmente existe un procedimiento de mitigación identificado por los analistas de Nubsec.
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1544,6 +1544,8 @@ static bool rtmutex_spin_on_owner(struct rt_mutex_base *lock,
*
* Must be called with lock->wait_lock held and interrupts disabled. It must
* have just failed to try_to_take_rt_mutex().
+ *
+ * When invoked from rt_mutex_start_proxy_lock() waiter::task != current !
*/
static void __sched remove_waiter(struct rt_mutex_base *lock,
struct rt_mutex_waiter *waiter)
@@ -1551,14 +1553,15 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
{
bool is_top_waiter = (waiter == rt_mutex_top_waiter(lock));
struct task_struct *owner = rt_mutex_owner(lock);
+ struct task_struct *waiter_task = waiter->task;
struct rt_mutex_base *next_lock;
lockdep_assert_held(&lock->wait_lock);
- raw_spin_lock(¤t->pi_lock);
- rt_mutex_dequeue(lock, waiter);
- current->pi_blocked_on = NULL;
- raw_spin_unlock(¤t->pi_lock);
+ scoped_guard(raw_spinlock, &waiter_task->pi_lock) {
+ rt_mutex_dequeue(lock, waiter);
+ waiter_task->pi_blocked_on = NULL;
+ }
/*
* Only update priority if the waiter was the highest priority
@@ -1594,7 +1597,7 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
raw_spin_unlock_irq(&lock->wait_lock);
rt_mutex_adjust_prio_chain(owner, RT_MUTEX_MIN_CHAINWALK, lock,
- next_lock, NULL, current);
+ next_lock, NULL, waiter_task);
Versiones Afectadas
| Nombre de producto | Versiones afectadas | Versiones no afectadas |
|---|---|---|
| Linux 26.04 LTS | Anteriores a 7.0.0-27.26 | 7.0.0-27.27 o versiones posteriores |
| Linux AWS 26.04 LTS | Anteriores a 7.0.0-1008.7 | 7.0.0-1008.8 o versiones posteriores |
| Linux GCP 26.04 LTS | Anteriores a 7.0.0-1007.6 | 7.0.0-1007.7 o versiones posteriores |
| Linux GKE | Anteriores a 24.04 LTS | 26.04 LTS o versiones posteriores |
| Linux IBM 26.04 LTS | Anteriores a 7.0.0-1009.8 | 7.0.0-1009.9 o versiones posteriores |
| Linux Nvidia 26.04 LTS | Anteriores a 7.0.0-1013.12 | 7.0.0-1013.13 o versiones posteriores |
| Linux Oracle 26.04 LTS | Anteriores a 7.0.0-1007.6 | 7.0.0-1007.7 o versiones posteriores |
| Linux Raspi 26.04 LTS | Anteriores a 7.0.0-1014.13 | 7.0.0-1014.14 o versiones posteriores |
| Linux Realtime 26.04 LTS | Anteriores a 7.0.0-27.27.0 | 7.0.0-27.27.1 o versiones posteriores |
| Linux Riscv 26.04 LTS | Anteriores a 7.0.0-27.27.0 | 7.0.0-27.27.1 o versiones posteriores |
| Linux NVIDIA BOS | Anteriores a 24.04 LTS | 26.04 LTS o versiones posteriores |
| Linux NVIDIA 7.0 | 26.04 LTS y anteriores a 22.04 LTS | 24.04 LTS |
| Linux OEM 7.0 26.04 LTS | Anteriores a 7.0.0-1008.7 | 7.0.0-1008.8 o versiones posteriores |
Recomendaciones
- Actualizar los kernels a las versiones parcheadas proporcionadas por la distribución lo antes posible.
- Aplicar hotfix de seguridad en sistemas que no puedan migrar al último kernel inmediatamente.
- Limitar el acceso local no confiable a sistemas críticos y controlar la ejecución de código por usuarios sin privilegios.
- Habilitar y mantener funciones de hardening del kernel (por ejemplo RANDOMIZE_KSTACK_OFFSET) cuando sea posible.
- Mantener actualizados runtimes de contenedores y aplicar políticas de aislamiento estrictas para reducir el riesgo de abuso local.
- Monitorizar logs y actividades locales inusuales que indiquen intentos de explotación y revisar avisos de seguridad de proveedores y distribuciones.
CVEs
Referencias
https://cyberinsider.com/ghostlock-flaw-survived-in-the-linux-kernel-code-for-15-years/
https://nebusec.ai/research/ionstack-part-2/
