CVE-2026-43499 · 荣耀 WIN RT (AAK-AN00) Root temporal — Notas de investigación

(todo escrito por deepseek, yo no entiendo nada)

Bootloader del dispositivo bloqueado permanentemente (ro.oem_unlock.supported vacío), sin fastboot, sin su persistente, sin Magisk. El único camino que queda es una vulnerabilidad del kernel. Este repositorio documenta el proceso completo desde «¿se puede atacar?» hasta «qué tan estable es después de atacar».

Naturaleza: root temporal, se pierde al reiniciar.

Descargo de responsabilidad

Este repositorio documenta un proceso de investigación de seguridad realizado en un dispositivo de mi propiedad, con el objetivo de comprender las causas y los límites de estabilidad de una condición de carrera PI en el kernel.

• No contiene ningún binario exploit ni payload de explotación ejecutable directamente — el payload y el framework provienen de proyectos públicos upstream; este repositorio solo los referencia, no los redistribuye.
• No proporciona tutoriales para eludir mecanismos de ningún fabricante específico, ni fomenta su uso en dispositivos no autorizados.
• Los offsets y direcciones de símbolos dentro del repositorio solo son válidos para el único build de kernel listado en este documento; al cambiar el kernel, todo queda invalidado.
• Los defectos relacionados ya fueron corregidos en upstream (ver abajo). El valor a largo plazo de este documento radica en «este registro en sí mismo» — una retrospectiva real de una vulnerabilidad de condición de carrera bajo condiciones no ideales, incluyendo todos sus efectos secundarios incómodos.

0. Conclusión en una frase

La única ruta que funcionó es:

CVE-2026-43499 (condición de carrera futex PI write-what-where) + portador rt_sigreturn
  → inyección LD_PRELOAD en proceso del dominio shell
  → dos etapas: primero poner SELinux en Permissive, luego cambiar task->real_cred / cred a init_cred
  → uid=0(root) context=u:r:kernel:s0, e implantar un daemon su

Pero lo que realmente vale la pena escribir no es «cómo obtener root» — es lo que ocurre después de obtenerlo.

Lo que se obtiene no es un root estable, sino un «estado que puede detonar en cualquier momento».

La primitiva de escritura del exploit inserta un rt_mutex_waiter falsificado en la cadena futex PI real, y el portador de este waiter es una pila del kernel / página rociada que será reutilizada por llamadas al sistema posteriores. Por lo tanto, desde el momento en que root se establece, cualquier cambio de planificación o prioridad a nivel de sistema puede pisarlo, provocando directamente un kernel panic y reinicio. Esto no es un bug, es el precio inherente de esta técnica de explotación — ver docs/03.

1. Límites de aplicabilidad (si no coinciden, todo el plan queda invalidado)

Por qué es imprescindible fijar la versión del kernel: el defecto fue corregido en 6.6.140, y este dispositivo tiene 6.6.118 < 6.6.140, por lo que sigue presente; además, todas las direcciones de símbolos del kernel del exploit y la «geometría del portador» están ancladas a este único build; al cambiar el kernel, la tabla de offsets queda invalidada de inmediato, y generalmente no es posible revertir.

2. Panorama completo de la ruta de escalada de privilegios

┌─ Materiales ──────────────────────────────────────────┐
│ boot.img + xbl_config.elf (extraídos del firmware del dispositivo) │
│        ↓ resolución de símbolos                        │
│ target.h (direcciones de símbolos del kernel, verificadas byte a byte con kallsyms) │
│        ↓ compilación                                   │
│ preload.so ──► /data/local/tmp/*.so en el dispositivo  │
└────────────────────────────────────────────────────────┘
                 ↓  inyección LD_PRELOAD
     ┌──────────── dos etapas (requiere dos procesos independientes) ────────────┐
     │ Etapa A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Etapa B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (realizado por el proceso "escritor preestablecido") │
     │         → setresuid(0,0,0) normalización                    │
     │         → implantar su embebido + daemon                    │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Tres cosas que deben hacerse correctamente (si se hacen mal, se bloquea o directamente hay panic):

1. Regla de orden inquebrantable: primero real_cred, luego cred. El orden inverso provoca permisos completos instantáneos y pérdida de control de los hilos.
2. Entre los dos cortes existe inevitablemente un estado transitorio con cred ≠ real_cred. En ese momento cualquier sched_setaffinity dará EPERM → bloqueo total de la ronda. La solución correcta es hacer fork del proceso "escritor preestablecido" antes del primer corte (con credenciales limpias); el proceso padre ejecuta el primer corte, el escritor ejecuta el segundo, y ninguno emite syscalls durante el estado transitorio.
3. El modelo de direcciones no depende de KASLR. Toda la explotación solo usa el alias de mapeo lineal alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), estable entre reinicios; el verdadero valor de la llamada "fase slide" es la autoverificación de la primitiva de escritura, no eludir KASLR.

Framework upstream: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Nota: esto no es GhostLock — GhostLock usa la ruta pselect, que no coincide con la geometría del punto de caída del waiter de este build, ver docs/06.

3. Índice

4. Cronología

5. Una frase para los que vengan después

Si también estás atacando un modelo con BL bloqueado, primero piensa claramente para qué quieres root, porque en este tipo de dispositivos root probablemente sea una ventana de solo unos diez minutos. Haz una lista de las operaciones que «requieren root y deben persistir entre reinicios», ejecútalas todas de una vez, y luego reboot a un estado limpio. No intentes «eliminar los efectos secundarios» — ese es el precio de la técnica en sí misma.