
Kernel exploit for CVE-2026-43499 on Samsung Galaxy A17 achieving root via KDP bypass, KASLR recovery, and forged workqueue execution with persistent shell.
Full user-to-root exploit chain for CVE-2026-43499 ("GhostLock") on the Samsung Galaxy A17 SM-A175F, running Android 16 / GKI 6.12.
The chain starts from the public GhostLock primitives and ends with a usermode helper executing as:
uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0
It also starts a persistent per-boot root shell through g4d / g4sh and exits without a kernel panic.
📖 Full technical write-up:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Research note
We did not discover CVE-2026-43499. Credit for the original vulnerability and IonStack research goes to Nebula Security.
This repository documents our independent port to the Samsung Galaxy A17, the changes required for Samsung's kernel protections, and a new final exploitation stage.
For authorized security research and educational purposes only.
| CVE | CVE-2026-43499 — "ghostlock" |
| Device | Samsung Galaxy A17 (SM-A175F, mt6789) |
| GPU | Mali-G57 |
| Kernel | 6.12.23-android16-5-abA175FXXS3BZA5-4k |
| Result | uid=0(root) / u:r:kernel:s0 |
| Root shell | g4d daemon + g4sh client |
| Persistence | Per-boot |
| Exploit exit | Clean, no kernel panic |
| Mitigations encountered | Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR |
| Supported firmware | A175FXXS3BZA5 (kernel 6.12.23) and A175FXXS6CZG1 (kernel 6.12.38, SPL 2026-07-05) — both device-verified, same chain |
The original ghostlock research provides the entry primitives:
pselect reclaim
↓
fake rt_mutex_waiter
↓
constrained rb-tree pointer write
On the Galaxy A17, however, the standard credential-patching endgame does not work.
KDP protects credential-related kernel data at EL2.
On this build, attempts to modify task credentials were silently dropped even when the target addresses were correct.
So instead of writing root credentials, this port makes the kernel execute with existing privileged credentials.
The final stage:
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
A forged work item is placed on a bound system_wq pool and triggered with a ptmx allocation/free storm.
The resulting usermode helper executes with init credentials.
No task credential overwrite is required.
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
Compared with the public OnePlus port, most stages after the initial write primitive were reworked.
The credential-patching endgame was replaced with a forged workqueue item targeting the usermode-helper execution path.
This avoids writing protected cred structures entirely.
The previous perf-event anchoring approach was unreliable on this device.
Instead, the exploit uses three slid pointers from the boot_id ctl_table entry:
procname
data
proc_handler
All three are cross-validated before accepting the slide.
cpu_pwq is discovered by walking:
system_wq → pwqs
rather than relying on a fixed device-specific offset.
The original channel leaves collateral changes to struct page state that can trigger PANIC_ON_OOPS during teardown.
The current chain avoids the teardown crash and has been demonstrated exiting cleanly after root.
The usermode helper starts:
g4d
which listens on the abstract Unix socket:
@ghostlockd
g4sh connects to it and provides either an interactive root shell or one-shot command execution.
/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"
This target combines several protections that break common Android kernel exploitation techniques:
This forced a different exploit strategy from the usual:
arbitrary RW → patch cred → disable SELinux
Instead:
arbitrary RW → recover runtime state → forge kernel work → execute usermode helper
Requires a recent 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
Produces:
ghostlock # exploit (ghostlock-czg1 for the CZG1 build)
g4d # static root-shell daemon
g4sh # root-shell client
Push the binaries:
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'
Run the reboot-aware exploit loop:
./scripts/rr_loop4.sh
After ROOTED:
adb shell /data/local/tmp/a/g4sh
Or execute a single command:
adb shell '/data/local/tmp/a/g4sh -c "id"'
Expected result:
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
The primitive is probabilistic and strongly dependent on boot conditions.
Successful exploitation may require repeated attempts. The included rr_loop4.sh script handles retries and reboot cycles automatically.
This is a research exploit, not an instant one-shot rooting tool.
qemu-e2e/ contains an end-to-end validation harness using the extracted Samsung kernel.
The harness was used to test:
g4d / g4sh round tripsThe Samsung kernel image itself is not included.
See:
qemu-e2e/
for setup instructions.
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
NebuSec:
https://nebusec.ai/research/ionstack-part-3/
https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack
https://github.com/JoinChang/ghostlock-oneplus
A deeper look at the Samsung Galaxy A17 port, KDP limitations, KASLR recovery, workqueue-based final stage, and root-shell implementation:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Real-device artifacts are available under:
examples/
including exploit logs and root-context verification.
Example:
uid=0(root)
gid=0(root)
groups=0(root)
context=u:r:kernel:s0
This proof of concept is provided for educational and authorized security research purposes only.
Only use it on devices and environments you own or have explicit permission to test.