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

Linux kernel privilege escalation exploit attempt based on CVE-2026-43499 (GhostLock) — Huawei Watch 4 Pro (MDS-AL00, armv7l)

Project Overview

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)

Device Information

Current Project Status

Core Blocking Issues

1. Second rb_erase Not Triggered (Root Cause)

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

2. iovstack and rt_mutex_waiter Misalignment

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:

• Tested 11 different offsets × left/right child = 22 layouts
• None successfully overwrote clear_refs_operations.write
• Possible reason: This kernel's stack layout (frame size, local variable positions) differs from ghostlock64's assumptions

3. sched_setattr PI Chain Walk Operates on Owner's Data

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

4. Additional Huawei Kernel Restrictions

• mmap(0, ..., MAP_FIXED, ...) returns -EINVAL, not the standard Linux -EACCES
• CONFIG_SECURITY_SELINUX_DEVELOP=n → selinux_state.enforcing field does not exist
• mremap → ENOSYS

Attempted Approaches

Key Addresses (from System.map of 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

External References (ARM64, not directly applicable)

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.

Repository File Structure

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

Conclusion

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.

Author's Note

Huawei, you've screwed me over. You burned 30 RMB of DeepSeek V4 Pro tokens on me.