Exploit de kernel para CVE-2026-43499 no Samsung Galaxy A17 que alcança root via bypass de KDP, recuperação de KASLR e execução de workqueue forjada com shell persistente.
Cadeia completa de exploit de usuário para root para CVE-2026-43499 ("GhostLock") no Samsung Galaxy A17 SM-A175F, executando Android 16 / GKI 6.12.
A cadeia começa a partir das primitivas públicas do GhostLock e termina com um usermode helper executando como:
uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0
Ele também inicia um shell root persistente por boot através de g4d / g4sh e encerra sem um kernel panic.
📖 Análise técnica completa:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Nota de pesquisa
Não descobrimos a CVE-2026-43499. O crédito pela vulnerabilidade original e pela pesquisa IonStack é da Nebula Security.
Este repositório documenta o nosso port independente para o Samsung Galaxy A17, as alterações necessárias para as proteções do kernel da Samsung e uma nova etapa final de exploração.
Apenas para fins de pesquisa de segurança autorizada e educacionais.
| CVE | CVE-2026-43499 — "ghostlock" |
| Dispositivo | Samsung Galaxy A17 (SM-A175F, mt6789) |
| GPU | Mali-G57 |
| Kernel | 6.12.23-android16-5-abA175FXXS3BZA5-4k |
| Resultado | uid=0(root) / u:r:kernel:s0 |
| Shell root | daemon g4d + cliente g4sh |
| Persistência | Por boot |
| Saída do exploit | Limpa, sem kernel panic |
| Mitigações encontradas | Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR |
| Firmware suportado | A175FXXS3BZA5 (kernel 6.12.23) e A175FXXS6CZG1 (kernel 6.12.38, SPL 2026-07-05) — ambos verificados no dispositivo, mesma cadeia |
A pesquisa original do ghostlock fornece as primitivas de entrada:
pselect reclaim
↓
fake rt_mutex_waiter
↓
constrained rb-tree pointer write
No Galaxy A17, porém, o desfecho padrão de correção de credenciais não funciona.
O KDP protege dados do kernel relacionados a credenciais no EL2.
Nesta build, as tentativas de modificar as credenciais da task foram silenciosamente descartadas mesmo quando os endereços de destino estavam corretos.
Assim, em vez de escrever credenciais de root, esta port faz o kernel executar com credenciais privilegiadas existentes.
O estágio final:
constrained kernel write
↓
physical read/write channel
↓
KASLR slide recovery
↓
discover system_wq / cpu_pwq
↓
forge work_struct
↓
call_usermodehelper_exec_work
↓
/system/bin/sh
↓
uid=0(root), u:r:kernel:s0
Um item de trabalho forjado é colocado em um pool system_wq vinculado e acionado com uma tempestade de alocação/liberação de ptmx.
O helper em modo usuário resultante é executado com credenciais de init.
Não é necessária a sobrescrita de credenciais de tarefa.
userspace shell (uid 2000)
│
▼
pselect / PI-futex primitive
│
▼
constrained aligned kernel pointer write
│
▼
forged pipe_buffer channel
│
▼
arbitrary physical read/write
│
├── recover KASLR slide
│
├── locate system_wq / cpu_pwq
│
└── prepare forged work_struct
│
▼
queue usermode-helper work
│
▼
ptmx storm wakes worker
│
▼
/system/bin/sh runs with init creds
│
▼
uid=0(root)
│
▼
g4d → @ghostlockd → g4sh
Em comparação com o port público do OnePlus, a maioria dos estágios após a primitiva de escrita inicial foi reformulada.
O desfecho de patching de credenciais foi substituído por um item de workqueue forjado direcionado ao caminho de execução do usermode-helper.
Isso evita escrever inteiramente em estruturas cred protegidas.
A abordagem anterior de ancoragem por perf-event era não confiável neste dispositivo.
Em vez disso, o exploit usa três ponteiros deslizados da entrada ctl_table de boot_id:
procname
data
proc_handler
Todos os três são validados de forma cruzada antes de aceitar o slide.
cpu_pwq é descoberto percorrendo:
system_wq → pwqs
em vez de depender de um deslocamento fixo específico do dispositivo.
O canal original deixa alterações colaterais no estado de struct page que podem acionar PANIC_ON_OOPS durante o encerramento.
A cadeia atual evita a falha no encerramento e foi demonstrada saindo de forma limpa após obter root.
O auxiliar de modo usuário inicia:
g4d
que escuta no socket Unix abstrato:
@ghostlockd
g4sh conecta-se a ele e fornece uma shell root interativa ou execução de comando único.
/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"
Este alvo combina várias proteções que quebram técnicas comuns de exploração do kernel Android:
Isso forçou uma estratégia de exploração diferente da usual:
arbitrary RW → patch cred → disable SELinux
Em vez disso:
arbitrary RW → recover runtime state → forge kernel work → execute usermode helper
Requer um Android NDK recente.
make # BZA5 firmware (kernel 6.12.23)
make czg1 # CZG1 firmware (kernel 6.12.38): per-target slide anchors,
# offsets are uname-keyed at runtime
Produz:
ghostlock # exploit (ghostlock-czg1 for the CZG1 build)
g4d # static root-shell daemon
g4sh # root-shell client
Envie os binários:
adb push ghostlock /data/local/tmp/a/g4
adb push g4d /data/local/tmp/a/g4d
adb push g4sh /data/local/tmp/a/g4sh
adb shell 'chmod 755 /data/local/tmp/a/g4 /data/local/tmp/a/g4d /data/local/tmp/a/g4sh'
Execute o loop de exploit com reconhecimento de reinicialização:
./scripts/rr_loop4.sh
Após ROOTED:
adb shell /data/local/tmp/a/g4sh
Ou execute um único comando:
adb shell '/data/local/tmp/a/g4sh -c "id"'
Resultado esperado:
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
A primitiva é probabilística e fortemente dependente das condições de boot.
A exploração bem-sucedida pode exigir tentativas repetidas. O script incluído rr_loop4.sh lida com novas tentativas e ciclos de reinicialização automaticamente.
Este é um exploit de pesquisa, não uma ferramenta de rooting instantânea de uso único.
qemu-e2e/ contém um harness de validação ponta a ponta usando o kernel Samsung extraído.
O harness foi usado para testar:
g4d / g4shA imagem do kernel Samsung em si não está incluída.
Veja:
qemu-e2e/
para instruções de configuração.
Makefile
src/ exploit source and device profiles
src/daemon/ g4d root daemon + g4sh client
docs/OFFSETS.md validated device offsets
docs/PORTING.md porting notes
examples/ proof-of-root artifacts
scripts/rr_loop4.sh reboot-aware exploit loop
qemu-e2e/ end-to-end QEMU validation