CVE-2026-43499 GhostLock — ARM32 Huawei Watch 4 Pro

Basierend auf CVE-2026-43499 (GhostLock) – Ein Linux-Kernel-Privilege-Escalation-Exploit-Versuch für die Huawei Watch 4 Pro (MDS-AL00, armv7l)

Projektübersicht

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)

Geräteinformationen

Aktueller Projektstatus

Kernblockaden

1. Zweite rb_erase wird nicht ausgelöst (Das grundlegendste Problem)

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).

2. iovstack und rt_mutex_waiter sind nicht ausgerichtet

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:

• 11 verschiedene Offsets × linkes/rechtes Kind = 22 Layouts getestet
• Keines konnte clear_refs_operations.write erfolgreich überschreiben
• Möglicher Grund: Das Stapellayout dieses Kernels (Frame-Größe, Position lokaler Variablen) unterscheidet sich von der Annahme in ghostlock64

3. sched_setattr PI-Kettendurchlauf bearbeitet Daten des Owners

sched_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.

4. Zusätzliche Einschränkungen des Huawei-Kernels

• mmap(0, ..., MAP_FIXED, ...) gibt -EINVAL zurück, nicht das standardmäßige Linux -EACCES
• CONFIG_SECURITY_SELINUX_DEVELOP=n → das Feld selinux_state.enforcing existiert nicht
• mremap → ENOSYS

Getestete Ansätze

Wichtige Adressen (System.map von MDS-AL00)

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

Externe Referenzen (ARM64, nicht direkt anwendbar)

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.

Repository-Dateistruktur

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

Fazit

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.

Anmerkung des Autors

Huawei, du hast mich umgebracht! Hast mir mein DeepSeek V4 Pro für 30 RMB Token verbrannt.