lkeld/cve-2026-43499-pocArma de prueba de concepto para CVE-2026-43499 (GhostLock), un fallo de rtmutex en el kernel de Linux que permite la escalada local de privilegios. Incluye cadenas de explotación por distribución, documentación técnica y pruebas de fiabilidad.
Investigación de armamento para CVE-2026-43499 (ghostlock).
el bug de la ruta proxy remove_water() de rtmutex que deja el pi_blocked_on de una tarea colgando en su propio marco de pila del kernel reventado.
La clase de bug y la estrategia de exploit original son crédito de nebusec (su write-up aquí)
todo lo demás en este repo es mi propio trabajo por distribución:
cada familia de kernel necesita primitivas materialmente diferentes y eso es lo que hace esto tan interesante.
El disparador de Ghostlock es completamente no privilegiado (tres futexes, dos hilos y sin namespaces). El proceso de convertir el puntero colgante en root es donde cada una de las distros diverge, esto se reduce a la geometría del marco, las mitigaciones, y lo que "bytes controlados en una dirección de kernel conocida" incluso significan, todo cambia. Este repo recopilará cadenas por familia objetivo.
| Objetivo | Cadena | Staging | Estado |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — página de alias physmap + pintor auxv + caminata sched_setscheduler | root-en-namespace (contenedor privilegiado) | funcionando, prueba de estrés 40/40 en arranques limpios |
RHEL/CentOS 7 — 3.10.0-693.el7 | misma cadena, geometría de marco medida | igual | componentes validados 10/10; solo pendiente una prueba de estrés |
consulta el WRITEUP.md de cada subdirectorio para el análisis técnico completo, la causa raíz, por qué la cadena estándar de la era 6.x no se transfiere,
los hallazgos de primitivas, lo que construí en su lugar, las geometrías de marco medidas y los datos relacionados con la fiabilidad.
donde las cosas se complican: la caminata valida el ->lock del waiter falsificado contra el lock que encontró a través de (BUG_ON(w->lock != lock) en 3.10), así que necesitas estructuras falsas en memoria direccionable por el kernel en una dirección que conocerías. esto es lo que difiere enormemente por kernel (el truco del área de entrada de CPU de la era 6.x que utilizó nebusec, no existe en 3.10, el7 aleatoriza el mapa base directo, etc.). Cada write-up documenta su propia respuesta.
el bug y el disparador: no necesitas privilegios, ni user namespaces, nada. cualquier usuario local funciona.
cada armamento declara su propio staging en su write-up. La cadena el7 se escenifica desde root-en-namespace (en la práctica: cualquier RCE en un contenedor privilegiado - esto se validó desde una instancia de MYSQL a través de su ruta de plugin UDF, que es una posición muy típica). El trabajo del lado del kernel después del staging usa solo:
/proc/self/pagemap con PFNs reales (in-ns CAP_SYS_ADMIN)/proc/kcore (in-ns CAP_SYS_RAWIO en el7)/proc/kallsyms sin enmascarar (kptr_restrict=0 o CAP_SYSLOG)Ninguno de esos es la vulnerabilidad en sí, son solo las conveniencias de staging que sustituyen a las filtraciones de información que aún no he construido.
En el7 específicamente, una cadena completamente no privilegiada está bloqueada por razones estructurales (el BUG_ON de 3.10, sin CEA, sin par de lock falso estático en el .data del kernel, gating de PFN de pagemap)
El write-up de el7 tiene el análisis completo y las direcciones de investigación, principalmente una primitiva de filtración de información de dirección de cabeza
panic_on_oops=1, una caminata incorrecta causará un pánico y resultará en una máquina muerta, así que trátalo como un ajuste parte de tu modelo de amenazas al probarel7/
WRITEUP.md write-up técnico completo para la cadena el7
ghostlock_el7.c poc de un solo archivo para ambos kernels probados
3bfdc63936dd ("rtmutex: Use waiter::task instead of current in
remove_waiter()"); seguimiento de NPD 40a25d59e85b