tc3650/cve-2026-43499-armv7ARM32 Linux-Kernel-Privilegieneskalations-Exploit für CVE-2026-43499 (GhostLock futex UAF) mit Ziel Huawei Watch 4 Pro, mit mehreren Exploit-Varianten und detaillierter Umgehungsanalyse.
Basierend auf CVE-2026-43499 (GhostLock) – Ein Linux-Kernel-Privilege-Escalation-Exploit-Versuch für die Huawei Watch 4 Pro (MDS-AL00, armv7l)
Dieses Projekt ist ein Exploit-Versuch für die GhostLock-Kernel-Sicherheitslücke auf dem Huawei Watch 4 Pro (MDS-AL00, Snapdragon SW5100, HarmonyOS 4.3.0 AOSP 12) Gerät, angepasst für die ARM 32-bit (armv7l) Architektur.
GhostLock (CVE-2026-43499) ist eine Kernel-Futex-PI-UAF-Sicherheitslücke, die Linux 2.6.39 bis 7.x betrifft. Das Ziel dieses Projekts ist es, eine vollständige Privilege-Escalation-Kette auf der Huawei-Uhr zu erreichen.
Original-Repository: MobiusM/CVE-2026-43499 (arm64 PoC)
| Parameter | Wert |
|---|---|
| Gerät | Huawei Watch 4 Pro (MDS-AL00) |
| Kernel | 5.4.161-perf (ARM32 armv7l) |
| System | HarmonyOS 4.3.0 (AOSP 12) |
| CPU | Snapdragon SW5100 |
| SELinux | Erzwingend (Enforcing) (CONFIG_SECURITY_SELINUX_DEVELOP=n) |
| KASLR | Ausgeschaltet |
| MMU | CONFIG_STRICT_KERNEL_RWX=y |
| Stack | NX (Kernel-Stack nicht ausführbar) |
| mmap(0) | Zusätzliche Huawei-Sperre (-EINVAL, nicht standardmäßig -EACCES) |
| Phase | Status | Erklärung |
|---|---|---|
| GhostLock FUTEX PI Auslösung | ✅ Erfolgreich verifiziert | FUTEX_CMP_REQUEUE_PI gibt EDEADLK (-35) zurück |
| PI-Kettendurchlauf ausgelöst | ✅ Verifiziert | sched_setattr löst PI-Kettendurchlauf aus |
| Zweite rb_erase | ❌ Kernblockade | Diese Kernel-PI-Kettenimplementierung führt keine zweite rb_erase aus |
| iovstack-Ausrichtung | ❌ Blockiert | 8-iov writev Spray überlappt nicht mit rt_mutex_waiter |
| mmap(0)-Umgehung | ❌ Blockiert | Zusätzliche Huawei-Kernel-Prüfung (-EINVAL) |
| fops-Hijack | ❌ Blockiert | Keine kontrollierte Arbitrary-Write-Primitive |
| cred-Überschreibung | ❌ Blockiert | Aufgrund der oben genannten Blockaden eingeschränkt |
| Privilege-Escalation abgeschlossen | ❌ | Nicht implementiert |
Auf Kernel 5.4.161 ARM32 wird nach dem Auslösen von EDEADLK durch FUTEX_CMP_REQUEUE_PI keine zweite rb_erase im PI-Kettendurchlauf ausgeführt. Die von GhostLock 64 verwendete UAF → zweite rb_erase-Schreibkette in die UAF-Seite ist auf diesem Kernel vollständig unwirksam.
Alle 8-iov writev Spray-Varianten schlagen fehl: sc[0] after = e3a0002a (Shellcode-Seite wurde nicht beschrieben).
Das 8-iov writev Spray von ghostlock64 verlässt sich darauf, dass das iovstack[8]-Array auf dem Kernelstapel die rt_mutex_waiter-Struktur überlappt. Auf diesem Kernel:
clear_refs_operations.write erfolgreich überschreibensched_setattr kann erfolgreich den PI-Kettendurchlauf auslösen (Verifiziert success=1600+), aber rb_erase arbeitet auf dem pi_tree_entry des OWNER-Threads (im kmalloc-Heap in task_struct), nicht auf den Stapeldaten des Waiter-Threads (fd_set writev Daten). Daher kann der pselect + sched_setattr-Ansatz nicht zur Kontrolle des Schreibwerts verwendet werden.
mmap(0, ..., MAP_FIXED, ...) gibt -EINVAL zurück, nicht das standardmäßige Linux -EACCESCONFIG_SECURITY_SELINUX_DEVELOP=n → das Feld selinux_state.enforcing existiert nichtmremap → ENOSYS| Ansatz | Ergebnis | Grund |
|---|---|---|
| ghostlock64 8-iov writev → FLPI | ❌ | Zweite rb_erase wird nicht ausgelöst |
| ghostlock64 + sched_setattr | ❌ | Gleicher Grund, PI-Kette erreicht UAF-Seite nicht |
| g62 3-iov | ❌ | Kann schreiben, aber Wert ist Stapeladresse, Stapel NX nicht ausführbar |
| pselect + sched_setattr | ❌ | rb_erase bearbeitet Heap-Daten des Owners |
| Waiter eigenes FLPI zweites | ❌ | EDEADLK schneller Pfad, liest Stapel nicht |
| iov-Offset-Scan (22 Layouts) | ❌ | Alle überlappen nicht |
| mm(0) / mremap Umgehung | ❌ | -EINVAL / ENOSYS |
| SELinux-Hook zurücksetzen | ❌ | Feld enforcing existiert nicht |
commit_creds: 0xC0140390
prepare_kernel_cred: 0xC014059C
proc_clear_refs_ops: 0xC0CAF280 (.write @ +12 = 0xC0CAF28C)
mmap_min_addr: 0xC12E8568
dac_mmap_min_addr: 0xC123C734
selinux_hooks[mmap]: 0xC0F64E1C
| Repository | Gerät | Kernel | Architektur |
|---|---|---|---|
| x-spy/CVE-2026-43499-popsicle | Xiaomi 17 Pro Max | 6.12.23 | ARM64 |
| pubglite55/oppo-ghostlock | OPPO Find N2 | 5.10.236 | ARM64 |
Beide Repositories verwenden pselect() + sched_setattr zum Auslösen der PI-Kette + physmap-Direktschreiben, und verlassen sich auf den direkten Map-Mechanismus von ARM64. ARM32 hat keinen direkten Map, und das PI-Kettenverhalten dieses Kernels unterscheidet sich.
CVE-2026-43499-armv7/
├── config/
│ └── kernel.config # Gerät Kernel .config (5.4.161-perf)
├── scripts/
│ ├── ghostlock_all.sh # Batch-Test-Skript
│ └── ghostlock_check.sh # Erkennungsskript
├── src/
│ ├── ghostlock64.c # Original 8-iov Doppel-erase PoC (Basisgerüst)
│ ├── ghostlock5-33.c # Frühe Iterationen (ghostlock5 ~ ghostlock33)
│ ├── ghostlock63.c # ghostlock 6.x 3-iov Variante
│ ├── g62_*.c # 3-iov Varianten (verschiedene Zieladressen)
│ ├── g62_8e.c # 8-iov Präzisionsspray (finale Version)
│ ├── g62_scan.c # Multi-iov Offset-Scan
│ ├── g62_self.c # Waiter selbst EDEADLK-Test
│ ├── g62_pispray.c # EDEADLK + slab spray + sched_setattr
│ ├── g62_rand.c # Write randomize_va_space Test
│ ├── gsu_v19.c # 8-iov + sched_setattr Auslösung
│ ├── gl_pselect*.c # pselect + sched_setattr Test
│ ├── gl_scan.c # fd_set Offset-Scan
│ ├── sc64.c # Shellcode Payload
│ ├── trigger*.c # Originaler trigger PoC (Überprüfung der Schwachstelle)
│ ├── ghostlock_root.c # Früher Root-Versuch
│ └── test_*.c # Kompilierungs-/Lauftests
├── README.md
├── ghostlock64 # 8-iov Doppel-erase PoC Binary
├── ghostlock63 # ghostlock 6.x 3-iov Binary
├── g62_* # 3-iov Varianten Binaries
├── gl_* # pselect Test Binaries
├── gsu # sc-page Hijack Variante
├── sc64 # Shellcode
├── trigger* # Originaler trigger PoC Binary
└── test_* # Test Binaries
Die PI-Kettenimplementierung dieser Kernelversion (5.4.161 ARM32) unterstützt die GhostLock-Doppel-rb_erase-Arbitrary-Write-Technik nicht. Alle bekannten CVE-2026-43499-Exploit-Ansätze sind auf diesem Gerät blockiert. Es müssen neue Write-0-Primitive oder andere Sicherheitslücken gefunden werden, um fortzufahren.
Huawei, du hast mich umgebracht! Hast mir mein DeepSeek V4 Pro für 30 RMB Token verbrannt.