GhostLock — CVE-2026-43499 no Samsung Galaxy A17

Cadeia de exploração completa 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 nas 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

Ela também inicia um shell root persistente por inicialização através de g4d / g4sh e sai sem um kernel panic.

📖 Artigo técnico completo:
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 sobre IonStack vai para a Nebula Security.

Este repositório documenta nossa portabilidade independente para o Samsung Galaxy A17, as alterações necessárias para as proteções de kernel da Samsung e um novo estágio final de exploração.

Apenas para pesquisa de segurança autorizada e fins educacionais.

Alvo


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 inicialização
Saída do exploit	Limpa, sem kernel panic
Mitigações encontradas	Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR

O que torna esta portabilidade diferente?

A pesquisa original do ghostlock fornece as primitivas de entrada:

pselect reclaim
      ↓
fake rt_mutex_waiter
      ↓
constrained rb-tree pointer write

No Galaxy A17, no entanto, o estágio final padrão de correção de credenciais não funciona.

O KDP da Samsung bloqueia a gravação de credenciais usual

O KDP protege dados do kernel relacionados a credenciais no EL2.

Nesta compilação, tentativas de modificar as credenciais de tarefas foram silenciosamente descartadas mesmo quando os endereços de destino estavam corretos.

Então, em vez de gravar credenciais de root, esta portabilidade faz o kernel executar com credenciais privilegiadas existentes.

Novo estágio final: execução forjada de workqueue

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 usermode helper resultante executa com as credenciais de init.

Nenhuma sobrescrita de credenciais de tarefa é necessária.

Cadeia do exploit

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

Principais mudanças de engenharia

Em comparação com a portabilidade pública para OnePlus, a maioria dos estágios após a primitiva de gravação inicial foi reformulada.

1. Novo estágio de root compatível com KDP

O estágio final de correção de credenciais foi substituído por um item forjado de workqueue que visa o caminho de execução do usermode helper.

Isso evita totalmente a gravação de estruturas cred protegidas.

2. Novo oráculo de slide do KASLR

A abordagem anterior de ancoragem por perf-event não era confiável neste dispositivo.

Em vez disso, o exploit usa três ponteiros deslocados pelo slide da entrada boot_id ctl_table:

procname
data
proc_handler

Os três são validados de forma cruzada antes de aceitar o slide.

3. Descoberta de workqueue em tempo de execução

cpu_pwq é descoberto percorrendo:

system_wq → pwqs

em vez de depender de um offset fixo específico do dispositivo.

4. Saída limpa do exploit

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 de encerramento e foi demonstrada saindo de forma limpa após o root.

5. Shell root

O usermode helper inicia:

g4d

que escuta no socket Unix abstrato:

@ghostlockd

g4sh conecta-se a ele e fornece um shell root interativo ou a execução de comando único (one-shot).

/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"

Por que o Galaxy A17 é interessante

Este alvo combina várias proteções que quebram técnicas comuns de exploração de kernel Android:

Samsung KDP — protege dados do kernel relacionados a credenciais no EL2
DEFEX — restringe a execução privilegiada a partir de caminhos não confiáveis
SELinux
PANIC_ON_OOPS / PANIC_ON_BUG
Grandes slides de KASLR arm64
Primitiva de gravação restrita somente a ponteiros

Isso forçou uma estratégia de exploit diferente da usual:

arbitrary RW → patch cred → disable SELinux

Em vez disso:

arbitrary RW → recover runtime state → forge kernel work → execute usermode helper

Compilação

Requer um Android NDK recente.

make

Produz:

ghostlock   # exploit
g4d         # static root-shell daemon
g4sh        # root-shell client

Execução

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 ciente de reinicializações:

./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

Confiabilidade

A primitiva é probabilística e fortemente dependente das condições de inicialização.

A exploração bem-sucedida pode exigir tentativas repetidas. O script incluído rr_loop4.sh lida automaticamente com novas tentativas e ciclos de reinicialização.

Este é um exploit de pesquisa, não uma ferramenta de root instantânea de one-shot.

Validação no QEMU

qemu-e2e/ contém um harness de validação de ponta a ponta usando o kernel Samsung extraído.

O harness foi usado para testar:

alterações na cadeia do exploit
tratamento do KASLR
forjamento de workqueue
execução do usermode helper
encerramento limpo do exploit
viagens de ida e volta entre g4d / g4sh

A imagem do kernel Samsung em si não está incluída.

Consulte:

qemu-e2e/

para instruções de configuração.

Estrutura do repositório

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

Pesquisas relacionadas

Pesquisa original GhostLock / IonStack

NebuSec:

https://nebusec.ai/research/ionstack-part-3/

https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack

Portabilidade para OnePlus

https://github.com/JoinChang/ghostlock-oneplus

Análise do Mobile Hacking Lab

Um olhar mais aprofundado sobre a portabilidade para o Samsung Galaxy A17, as limitações do KDP, a recuperação do KASLR, o estágio final baseado em workqueue e a implementação do shell root:

https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell

Prova de root

Os artefatos de dispositivo real estão disponíveis em:

examples/

incluindo logs do exploit e verificação do contexto de root.

Exemplo:

uid=0(root)
gid=0(root)
groups=0(root)
context=u:r:kernel:s0

Aviso legal

Esta prova de conceito é fornecida apenas para fins educacionais e de pesquisa de segurança autorizada.

Use-a apenas em dispositivos e ambientes que você possui ou para os quais tenha permissão explícita de teste.

ghostlock-a17

Mais Populares