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

Tentativa de exploração de privilégio no kernel Linux baseada em CVE-2026-43499 (GhostLock) — Huawei Watch 4 Pro (MDS-AL00, armv7l)

Visão Geral do Projeto

Este projeto é uma tentativa de exploração da vulnerabilidade do kernel GhostLock no dispositivo Huawei Watch 4 Pro (MDS-AL00, Snapdragon SW5100, HarmonyOS 4.3.0 AOSP 12), adaptado para arquitetura ARM 32-bit (armv7l).

GhostLock (CVE-2026-43499) é uma vulnerabilidade de kernel futex PI UAF que afeta o Linux 2.6.39 a 7.x. O objetivo deste projeto é completar a cadeia completa de elevação de privilégio no relógio da Huawei.

Repositório original: MobiusM/CVE-2026-43499 (PoC para arm64)

Informações do Dispositivo

Status Atual do Projeto

Problemas Centrais de Bloqueio

1. Segundo rb_erase não acionado (problema mais fundamental)

No kernel 5.4.161 ARM32, após o FUTEX_CMP_REQUEUE_PI acionar EDEADLK, a travessia da cadeia PI não executa o segundo rb_erase. A exploração em cadeia do GhostLock 64 que depende de UAF → escrita do segundo rb_erase na página UAF falha completamente neste kernel.

Todas as variantes de spray de 8-iov writev falham: sc[0] after = e3a0002a (a página de shellcode não foi escrita).

2. iovstack não alinhado com rt_mutex_waiter

O spray de 8-iov writev do ghostlock64 depende da sobreposição do array iovstack[8] na pilha do kernel com a estrutura rt_mutex_waiter. Neste kernel:

• Testadas 11 compensações diferentes × filho esquerdo/direito = 22 layouts
• Nenhum conseguiu sobrescrever com sucesso clear_refs_operations.write
• Possível causa: o layout da pilha deste kernel (tamanho do frame, posição das variáveis locais) é diferente do assumido pelo ghostlock64

3. A travessia da cadeia PI do sched_setattr opera nos dados do owner

sched_setattr consegue acionar com sucesso a travessia da cadeia PI (verificado success=1600+), mas rb_erase opera no pi_tree_entry da thread OWNER (localizado em task_struct no heap kmalloc), e não nos dados da pilha da thread waiter (dados fd_set writev).

Portanto, a rota pselect + sched_setattr também não pode ser usada para controlar o valor escrito.

4. Restrições adicionais do kernel da Huawei

• mmap(0, ..., MAP_FIXED, ...) retorna -EINVAL, não o -EACCES padrão do Linux
• CONFIG_SECURITY_SELINUX_DEVELOP=n → o campo selinux_state.enforcing não existe
• mremap → ENOSYS

Rotas Tentadas

Endereços Chave (System.map do 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

Referências Externas (ARM64, não diretamente aplicável)

Ambos os repositórios usam pselect() + sched_setattr para acionar a cadeia PI + escrita direta no physmap, dependendo do mecanismo de direct map do ARM64. ARM32 não tem direct map, e o comportamento da cadeia PI deste kernel é diferente.

Estrutura de Arquivos do Repositório

CVE-2026-43499-armv7/
├── config/
│   └── kernel.config       # kernel config do dispositivo (5.4.161-perf)
├── scripts/
│   ├── ghostlock_all.sh    # Script de teste em lote
│   └── ghostlock_check.sh  # Script de verificação
├── src/
│   ├── ghostlock64.c       # PoC original de 8-iov duplo erase (estrutura base)
│   ├── ghostlock5-33.c     # Versões de iteração inicial (ghostlock5 ~ ghostlock33)
│   ├── ghostlock63.c       # Variante 3-iov do ghostlock 6.x
│   ├── g62_*.c             # Variantes 3-iov (diferentes endereços alvo)
│   ├── g62_8e.c            # Spray preciso de 8-iov (versão final)
│   ├── g62_scan.c          # Varredura de múltiplas compensações iov
│   ├── g62_self.c          # Teste de auto-acionamento EDEADLK do waiter
│   ├── g62_pispray.c       # EDEADLK + slab spray + sched_setattr
│   ├── g62_rand.c          # Teste de escrita de randomize_va_space
│   ├── gsu_v19.c           # Gatilho 8-iov + sched_setattr
│   ├── gl_pselect*.c       # Teste pselect + sched_setattr
│   ├── gl_scan.c           # Varredura de compensação fd_set
│   ├── sc64.c              # Payload shellcode
│   ├── trigger*.c          # PoC de gatilho original (verificar existência da vulnerabilidade)
│   ├── ghostlock_root.c    # Tentativa inicial de root
│   └── test_*.c            # Teste de compilação/execução
├── README.md
├── ghostlock64             # PoC binário 8-iov duplo erase
├── ghostlock63             # Binário variante 3-iov ghostlock 6.x
├── g62_*                   # Binários variantes 3-iov
├── gl_*                    # Binários de teste pselect
├── gsu                     # Variante de sequestro sc-page
├── sc64                    # Shellcode
├── trigger*                # PoC de gatilho original binário
└── test_*                  # Binários de teste

Conclusão

A implementação da cadeia PI desta versão do kernel (5.4.161 ARM32) não suporta a técnica de escrita arbitrária de duplo rb_erase do GhostLock. Todas as rotas de exploração conhecidas do CVE-2026-43499 são bloqueadas neste dispositivo. É necessário descobrir novas primitivas de escrita de zero ou outras vulnerabilidades para continuar.

Nota do Autor

Huawei, você me lascou, queimou meu token do deepseek V4 Pro de 30 RMB.