tc3650/cve-2026-43499-armv7ARM32 Linux kernel privilege escalation exploit for CVE-2026-43499 (GhostLock futex UAF) targeting Huawei Watch 4 Pro with multiple exploitation variants and detailed bypass analysis.
Linux kernel privilege escalation exploit attempt based on CVE-2026-43499 (GhostLock) — Huawei Watch 4 Pro (MDS-AL00, armv7l)
This project is a GhostLock kernel vulnerability exploit attempt targeting the Huawei Watch 4 Pro (MDS-AL00, Snapdragon SW5100, HarmonyOS 4.3.0 AOSP 12) device, adapted for the ARM 32-bit (armv7l) architecture.
GhostLock (CVE-2026-43499) is a kernel futex PI UAF vulnerability affecting Linux 2.6.39 through 7.x. The goal of this project is to complete a full privilege escalation chain on the Huawei watch.
Original repository: MobiusM/CVE-2026-43499 (arm64 version PoC)
| Parameter | Value |
|---|---|
| Device | Huawei Watch 4 Pro (MDS-AL00) |
| Kernel | 5.4.161-perf (ARM32 armv7l) |
| System | HarmonyOS 4.3.0 (AOSP 12) |
| CPU | Snapdragon SW5100 |
| SELinux | Enforcing (CONFIG_SECURITY_SELINUX_DEVELOP=n) |
| KASLR | Disabled |
| MMU | CONFIG_STRICT_KERNEL_RWX=y |
| Stack | NX (kernel stack non-executable) |
| mmap(0) | Huawei extra blocking (-EINVAL, non-standard -EACCES) |
| Phase | Status | Description |
|---|---|---|
| GhostLock FUTEX PI Trigger | ✅ Verified | FUTEX_CMP_REQUEUE_PI returns EDEADLK (-35) |
| PI Chain Walk Trigger | ✅ Verified | sched_setattr triggers PI chain walk |
| Second rb_erase | ❌ Core Blocking | This kernel's PI chain implementation does not perform a second rb_erase |
| iovstack Alignment | ❌ Blocked | 8-iov writev spray does not overlap with rt_mutex_waiter |
| mmap(0) Bypass | ❌ Blocked | Huawei kernel additional check (-EINVAL) |
| fops hijack | ❌ Blocked | No controlled arbitrary write primitive |
| cred Overwrite | ❌ Blocked | Limited by above blocking points |
| Privilege Escalation Complete | ❌ | Not achieved |
On kernel 5.4.161 ARM32, after FUTEX_CMP_REQUEUE_PI triggers EDEADLK, the PI chain walk does not perform a second rb_erase. The chain exploit that GhostLock 64 relies on (UAF → second rb_erase writes to UAF page) is completely ineffective on this kernel.
All 8-iov writev spray variants fail: sc[0] after = e3a0002a (shellcode page not written).
ghostlock64's 8-iov writev spray relies on the iovstack[8] array on the kernel stack overlapping with the rt_mutex_waiter structure. On this kernel:
clear_refs_operations.writesched_setattr can successfully trigger a PI chain walk (verified success=1600+), but rb_erase operates on the OWNER thread's pi_tree_entry (in the task_struct on the kmalloc heap), not the waiter thread's stack data (fd_set writev data).
Therefore, the pselect + sched_setattr route cannot be used to control the write value.
mmap(0, ..., MAP_FIXED, ...) returns -EINVAL, not the standard Linux -EACCESCONFIG_SECURITY_SELINUX_DEVELOP=n → selinux_state.enforcing field does not existmremap → ENOSYS| Approach | Result | Reason |
|---|---|---|
| ghostlock64 8-iov writev → FLPI | ❌ | Second rb_erase not triggered |
| ghostlock64 + sched_setattr | ❌ | Same, PI chain does not reach UAF page |
| g62 3-iov | ❌ | Can write but value is stack address, stack NX prevents execution |
| pselect + sched_setattr | ❌ | rb_erase operates on owner's heap data |
| waiter self-FLPI second | ❌ | EDEADLK fast path, does not read stack |
| iov offset scan (22 layouts) | ❌ | All non-overlapping |
| mmap(0) / mremap bypass | ❌ | -EINVAL / ENOSYS |
| selinux hook zeroing | ❌ | enforcing field does not exist |
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 | Device | Kernel | Architecture |
|---|---|---|---|
| x-spy/CVE-2026-43499-popsicle | Xiaomi 17 Pro Max | 6.12.23 | ARM64 |
| pubglite55/oppo-ghostlock | OPPO Find N2 | 5.10.236 | ARM64 |
Both repositories use pselect() + sched_setattr to trigger the PI chain + physmap direct write, relying on ARM64's direct map mechanism. ARM32 has no direct map, and this kernel's PI chain behavior is different.
CVE-2026-43499-armv7/
├── config/
│ └── kernel.config # Device kernel .config (5.4.161-perf)
├── scripts/
│ ├── ghostlock_all.sh # Batch test script
│ └── ghostlock_check.sh # Detection script
├── src/
│ ├── ghostlock64.c # Original 8-iov dual erase PoC (base framework)
│ ├── ghostlock5-33.c # Early iteration versions (ghostlock5 ~ ghostlock33)
│ ├── ghostlock63.c # ghostlock 6.x 3-iov variant
│ ├── g62_*.c # 3-iov variants (different target addresses)
│ ├── g62_8e.c # 8-iov precise spray (final version)
│ ├── g62_scan.c # Multi-iov offset scan
│ ├── g62_self.c # Waiter self-trigger EDEADLK test
│ ├── g62_pispray.c # EDEADLK + slab spray + sched_setattr
│ ├── g62_rand.c # Test writing randomize_va_space
│ ├── gsu_v19.c # 8-iov + sched_setattr trigger
│ ├── gl_pselect*.c # pselect + sched_setattr tests
│ ├── gl_scan.c # fd_set offset scan
│ ├── sc64.c # Shellcode payload
│ ├── trigger*.c # Original trigger PoC (verify vulnerability)
│ ├── ghostlock_root.c # Early root attempt
│ └── test_*.c # Compile/run tests
├── README.md
├── ghostlock64 # 8-iov dual erase PoC binary
├── ghostlock63 # ghostlock 6.x 3-iov binary
├── g62_* # 3-iov variant binaries
├── gl_* # pselect test binaries
├── gsu # sc-page hijack variant
├── sc64 # Shellcode
├── trigger* # Original trigger PoC binaries
└── test_* # Test binaries
The PI chain implementation of this kernel version (5.4.161 ARM32) does not support GhostLock's dual rb_erase arbitrary write technique. All known CVE-2026-43499 exploitation routes are blocked on this device. A new write-0 primitive or other vulnerabilities need to be discovered to proceed.
Huawei, you've screwed me over. You burned 30 RMB of DeepSeek V4 Pro tokens on me.