GhostLock — CVE-2026-43499 su Samsung Galaxy A17

Catena di exploit completa da utente a root per CVE-2026-43499 ("GhostLock") su Samsung Galaxy A17 SM-A175F, con Android 16 / GKI 6.12.

La catena parte dalle primitive GhostLock pubbliche e termina con un usermode helper eseguito come:

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

Avvia inoltre una shell di root persistente a ogni avvio tramite g4d / g4sh e termina senza kernel panic.

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

Nota di ricerca

Non abbiamo scoperto CVE-2026-43499. Il merito della vulnerabilità originale e della ricerca IonStack va a Nebula Security.

Questo repository documenta il nostro porting indipendente su Samsung Galaxy A17, le modifiche richieste dalle protezioni del kernel Samsung e una nuova fase finale di exploitation.

Solo per ricerca sulla sicurezza autorizzata e scopi educativi.

Target

Cosa rende diverso questo porting?

La ricerca originale di ghostlock fornisce le primitive di ingresso:

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

Su Galaxy A17, tuttavia, l'endgame standard di modifica delle credenziali non funziona.

Samsung KDP blocca la scrittura usuale delle credenziali

KDP protegge i dati del kernel correlati alle credenziali a livello EL2.

Su questa build, i tentativi di modificare le credenziali dei task sono stati silenziosamente ignorati anche quando gli indirizzi target erano corretti.

Quindi, invece di scrivere credenziali di root, questo porting fa sì che il kernel esegua con credenziali privilegiate già esistenti.

Nuovo endgame: esecuzione tramite workqueue contraffatto

La fase finale:

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

Un work item contraffatto viene inserito in un pool system_wq bound e attivato tramite uno storm di allocazione/rilascio di ptmx.

L'usermode helper risultante viene eseguito con le credenziali di init.

Non è richiesta alcuna sovrascrittura delle credenziali dei task.

Catena di 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

Modifiche ingegneristiche principali

Rispetto al porting pubblico per OnePlus, la maggior parte delle fasi successive alla primitiva di scrittura iniziale è stata rielaborata.

1. Nuova fase di root compatibile con KDP

L'endgame di modifica delle credenziali è stato sostituito con un work item contraffatto che prende di mira il percorso di esecuzione dell'usermode helper.

Questo evita del tutto di scrivere strutture cred protette.

2. Nuovo oracolo per lo slide KASLR

Il precedente approccio di ancoraggio basato su perf-event era inaffidabile su questo dispositivo.

L'exploit usa invece tre puntatori slittati dalla voce ctl_table di boot_id:

procname
data
proc_handler

Tutti e tre vengono convalidati in modo incrociato prima di accettare lo slide.

3. Scoperta runtime della workqueue

cpu_pwq viene individuato percorrendo:

system_wq → pwqs

invece di affidarsi a un offset fisso specifico del dispositivo.

4. Uscita pulita dell'exploit

Il canale originale lascia modifiche collaterali allo stato di struct page che possono innescare PANIC_ON_OOPS durante il teardown.

La catena attuale evita il crash in fase di teardown e ha dimostrato di terminare pulitamente dopo il root.

5. Shell di root

L'usermode helper avvia:

g4d

che resta in ascolto sul socket Unix astratto:

@ghostlockd

g4sh si connette ad esso e fornisce una shell di root interattiva o l'esecuzione di un singolo comando.

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

Perché Galaxy A17 è interessante

Questo target combina diverse protezioni che rompono le tecniche comuni di exploitation del kernel Android:

• Samsung KDP — protegge i dati del kernel correlati alle credenziali a livello EL2
• DEFEX — limita l'esecuzione privilegiata da percorsi non affidabili
• SELinux
• PANIC_ON_OOPS / PANIC_ON_BUG
• Slide KASLR arm64 ampi
• Primitiva di scrittura limitata al solo puntatore

Questo ha imposto una strategia di exploit diversa dal solito:

arbitrary RW → patch cred → disable SELinux

Invece:

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

Build

Richiede un Android NDK recente.

make

Produce:

ghostlock   # exploit
g4d         # demone statico per la shell di root
g4sh        # client per la shell di root

Esecuzione

Invia i binari:

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'

Esegui il loop di exploit con gestione dei riavvii:

./scripts/rr_loop4.sh

Dopo ROOTED:

adb shell /data/local/tmp/a/g4sh

Oppure esegui un singolo comando:

adb shell '/data/local/tmp/a/g4sh -c "id"'

Risultato atteso:

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

Affidabilità

La primitiva è probabilistica e dipende fortemente dalle condizioni di avvio.

Un exploitation riuscita può richiedere tentativi ripetuti. Lo script incluso rr_loop4.sh gestisce automaticamente i nuovi tentativi e i cicli di riavvio.

Questo è un exploit di ricerca, non uno strumento istantaneo di rooting one-shot.

Validazione QEMU

qemu-e2e/ contiene un harness di validazione end-to-end che usa il kernel Samsung estratto.

L'harness è stato usato per testare:

• le modifiche alla catena di exploit
• la gestione di KASLR
• la creazione del workqueue contraffatto
• l'esecuzione dell'usermode helper
• il teardown pulito dell'exploit
• i round trip di g4d / g4sh

L'immagine del kernel Samsung stesso non è inclusa.

Vedi:

qemu-e2e/

per le istruzioni di configurazione.

Struttura del repository

Makefile
src/                  sorgente dell'exploit e profili dispositivo
src/daemon/           demone di root g4d + client g4sh
docs/OFFSETS.md       offset dispositivo validati
docs/PORTING.md       note sul porting
examples/             artefatti di prova del root
scripts/rr_loop4.sh   loop di exploit con gestione dei riavvii
qemu-e2e/             validazione QEMU end-to-end

Ricerche correlate

Ricerca originale GhostLock / IonStack

NebuSec:

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

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

Porting OnePlus

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

Articolo di Mobile Hacking Lab

Uno sguardo più approfondito al porting per Samsung Galaxy A17, ai limiti di KDP, al recupero di KASLR, alla fase finale basata su workqueue e all'implementazione della shell di root:

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

Prova del root

Gli artefatti reali del dispositivo sono disponibili in:

examples/

inclusi i log dell'exploit e la verifica del contesto root.

Esempio:

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

Disclaimer

Questa proof of concept è fornita solo per scopi educativi e di ricerca sulla sicurezza autorizzata.

Usala esclusivamente su dispositivi e ambienti di tua proprietà o per i quali hai il permesso esplicito di testare.