CVE-2026-43499 GhostLock — ARM32 Huawei Watch 4 Pro

Intento de explotación de escalada de privilegios del kernel de Linux basado en CVE-2026-43499 (GhostLock) — Huawei Watch 4 Pro (MDS-AL00, armv7l)

Resumen del proyecto

Este proyecto es un intento de explotación del kernel mediante la vulnerabilidad GhostLock dirigido al dispositivo Huawei Watch 4 Pro (MDS-AL00, Snapdragon SW5100, HarmonyOS 4.3.0 AOSP 12), adaptado para la arquitectura ARM de 32 bits (armv7l).

GhostLock (CVE-2026-43499) es una vulnerabilidad UAF de futex PI del kernel de Linux que afecta a las versiones 2.6.39 a 7.x. El objetivo de este proyecto es completar la cadena completa de escalada de privilegios en el reloj de Huawei.

Repositorio original: MobiusM/CVE-2026-43499 (PoC para arm64)

Información del dispositivo

Estado actual del proyecto

Problemas de bloqueo principales

1. El segundo rb_erase no se dispara (el problema más fundamental)

En el kernel 5.4.161 ARM32, después de que FUTEX_CMP_REQUEUE_PI activa EDEADLK, el recorrido de la cadena PI no ejecuta el segundo rb_erase. La explotación encadenada de GhostLock 64, que depende de UAF → segundo rb_erase escribiendo en la página UAF, falla por completo en este kernel.

Todas las variantes de rociado writev de 8-iov fallan: sc[0] after = e3a0002a (la página del shellcode no ha sido escrita).

2. iovstack no se alinea con rt_mutex_waiter

El rociado writev de 8-iov de ghostlock64 depende de que el array iovstack[8] en la pila del kernel se superponga con la estructura rt_mutex_waiter. En este kernel:

• Se probaron 11 compensaciones diferentes × hijo izquierdo/derecho = 22 diseños
• Ninguno logró sobrescribir clear_refs_operations.write
• Posible causa: el diseño de la pila de este kernel (tamaño del marco, posiciones de las variables locales) difiere del que asume ghostlock64

3. El recorrido de la cadena PI de sched_setattr opera sobre los datos del owner

sched_setattr puede activar correctamente el recorrido de la cadena PI (verificado con success=1600+), pero rb_erase opera sobre pi_tree_entry del hilo OWNER (ubicado en el task_struct del montón kmalloc), no sobre los datos de la pila del hilo waiter (los datos de writev del fd_set).

Por lo tanto, la ruta pselect + sched_setattr tampoco se puede usar para controlar el valor escrito.

4. Limitaciones adicionales del kernel de Huawei

• mmap(0, ..., MAP_FIXED, ...) devuelve -EINVAL, no el -EACCES estándar de Linux
• CONFIG_SECURITY_SELINUX_DEVELOP=n → el campo selinux_state.enforcing no existe
• mremap → ENOSYS

Rutas probadas

Direcciones clave (System.map de MDS-AL00)

commit_creds:           0xC0140390
prepare_kernel_cred:    0xC014059C
proc_clear_refs_ops:    0xC0CAF280  (.write @ +12 = 0xC0CAF28C)
mmap_min_addr:          0xC12E8568
dac_mmap_min_addr:      0xC123C734
selinux_hooks[mmap]:    0xC0F64E1C

Referencias externas (ARM64, no aplican directamente)

Ambos repositorios usan pselect() + sched_setattr para activar la cadena PI + escritura directa de physmap, y dependen del mecanismo de mapeo directo de ARM64. ARM32 no tiene direct map, y el comportamiento de la cadena PI de este kernel es diferente.

Estructura de archivos del repositorio

CVE-2026-43499-armv7/
├── config/
│   └── kernel.config       # 设备内核 .config (5.4.161-perf)
├── scripts/
│   ├── ghostlock_all.sh    # 批量测试脚本
│   └── ghostlock_check.sh  # 检测脚本
├── src/
│   ├── ghostlock64.c       # 原始 8-iov 双 erase PoC (基础框架)
│   ├── ghostlock5-33.c     # 早期迭代版本 (ghostlock5 ~ ghostlock33)
│   ├── ghostlock63.c       # ghostlock 6.x 3-iov 变种
│   ├── g62_*.c             # 3-iov 变种 (不同目标地址)
│   ├── g62_8e.c            # 8-iov 精确喷溅 (最终版)
│   ├── g62_scan.c          # 多 iov 偏移扫描
│   ├── g62_self.c          # waiter 自触发 EDEADLK 测试
│   ├── g62_pispray.c       # EDEADLK + slab spray + sched_setattr
│   ├── g62_rand.c          # 写 randomize_va_space 测试
│   ├── gsu_v19.c           # 8-iov + sched_setattr 触发
│   ├── gl_pselect*.c       # pselect + sched_setattr 测试
│   ├── gl_scan.c           # fd_set 偏移扫描
│   ├── sc64.c              # shellcode payload
│   ├── trigger*.c          # 原始触发 PoC (验证漏洞存在)
│   ├── ghostlock_root.c    # 早期 root 尝试
│   └── test_*.c            # 编译/运行测试
├── README.md
├── ghostlock64             # 8-iov 双 erase PoC 二进制
├── ghostlock63             # ghostlock 6.x 3-iov 二进制
├── g62_*                   # 3-iov 变种二进制
├── gl_*                    # pselect 测试二进制
├── gsu                     # sc-page hijack 变种
├── sc64                    # shellcode
├── trigger*                # 原始触发 PoC 二进制
└── test_*                  # 测试二进制

Conclusión

La implementación de la cadena PI de esta versión del kernel (5.4.161 ARM32) no admite la técnica de escritura arbitraria de doble rb_erase de GhostLock. Todas las rutas de explotación conocidas de CVE-2026-43499 están bloqueadas en este dispositivo. Se necesita descubrir una nueva primitiva de escritura de ceros u otra vulnerabilidad para poder continuar.

Nota del autor

Huawei, me la jugaste: me quemaste 30 RMB en tokens de DeepSeek V4 Pro.