## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-TC3650-CVE-2026-43499-ARMV7
# CVE-2026-43499 GhostLock — ARM32 Huawei Watch 4 Pro
> 基于 CVE-2026-43499 (GhostLock) 的 Linux 内核提权漏洞利用尝试 — **Huawei Watch 4 Pro (MDS-AL00, armv7l)**
   
## 项目概述
本项目是针对 **Huawei Watch 4 Pro (MDS-AL00, Snapdragon SW5100, HarmonyOS 4.3.0 AOSP 12)** 设备的 GhostLock 内核漏洞利用尝试，在 **ARM 32-bit (armv7l)** 架构上适配。
GhostLock (CVE-2026-43499) 是一个影响 Linux 2.6.39 到 7.x 的内核 futex PI UAF 漏洞。本项目的目标是在华为手表上完成完整的提权链。
**原仓库** : MobiusM/CVE-2026-43499 (arm64 版 PoC)
* * *
## 设备信息
参数| 值
---|---
设备| Huawei Watch 4 Pro (MDS-AL00)
内核| 5.4.161-perf (ARM32 armv7l)
系统| HarmonyOS 4.3.0 (AOSP 12)
CPU| Snapdragon SW5100
SELinux| Enforcing (`CONFIG_SECURITY_SELINUX_DEVELOP=n`)
KASLR| 关闭
MMU| `CONFIG_STRICT_KERNEL_RWX=y`
栈| NX (内核栈不可执行)
mmap(0)| 华为额外拦截 (-EINVAL，非标准 -EACCES)
* * *
## 当前项目状态
* * *
## 核心阻塞问题
### 1\. 第二次 rb_erase 不触发 (最根本的问题)
在 kernel 5.4.161 ARM32 上，FUTEX_CMP_REQUEUE_PI 触发 EDEADLK 后，PI 链遍历**不执行第二次 rb_erase** 。GhostLock 64 依赖的 UAF → 第二次 rb_erase 写入 UAF 页的链式利用在此内核上完全失效。
所有 8-iov writev 喷溅变种均失败：`sc[0] after = e3a0002a` (壳码页未被写入)。
### 2\. iovstack 与 rt_mutex_waiter 不对齐
ghostlock64 的 8-iov writev 喷溅依赖内核栈上 `iovstack[8]` 数组与 `rt_mutex_waiter` 结构体重叠。在此内核上：
* 测试了 11 种不同偏移 × 左右孩子 = 22 种布局
* 无一种能成功改写 `clear_refs_operations.write`
* 可能原因：此内核的栈布局（帧大小、局部变量位置）与 ghostlock64 假设的不同
### 3\. sched_setattr PI 链遍历操作 owner 的数据
sched_setattr 能成功触发 PI 链遍历（已验证 `success=1600+`），但 `rb_erase` 操作的是 **OWNER 线程** 的 `pi_tree_entry`（位于 kmalloc 堆上的 task_struct 中），而不是 waiter 线程的栈数据（fd_set writev 数据）。
因此 pselect + sched_setattr 路线也无法用于控制写值。
### 4\. 华为内核额外限制
* `mmap(0, ..., MAP_FIXED, ...)` 返回 -EINVAL，不是标准 Linux 的 -EACCES
* `CONFIG_SECURITY_SELINUX_DEVELOP=n` → `selinux_state.enforcing` 字段不存在
* `mremap` → ENOSYS
* * *
## 尝试过的路线
* * *
## 关键地址 (System.map from MDS-AL00)
root@kitploit:~
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
* * *
## 外部参考 (ARM64，不直接适用)
仓库| 设备| 内核| 架构
---|---|---|---
x-spy/CVE-2026-43499-popsicle| Xiaomi 17 Pro Max
两个仓库均使用 `pselect()` \+ `sched_setattr` 触 PI 链 + physmap 直写，依赖 ARM64 的 direct map 机制。ARM32 无 direct map，且此内核的 PI 链行为不同。
* * *
## 仓库文件结构
root@kitploit:~
CVE-2026-43499-armv7/
├── config/
│ └── kernel.config # 设备内核 .config (5.4.161-perf)
├── scripts/
│ ├── ghostlock_all.sh # 批量测试脚本
│ └── ghostlock_check.sh # 检测脚本
├── src/
│ ├── ghostlock64.c # 原始 8-iov 双 erase PoC (基础框架)
│ ├── ghostlock5-33.c # 早期迭代版本 (ghostlock5 ~ ghostlock33)
│ ├── ghostlock63.c # ghostlock 6.x 3-iov 变种
│ ├── g62_*.c # 3-iov 变种 (不同目标地址)
│ ├── g62_8e.c # 8-iov 精确喷溅 (最终版)
│ ├── g62_scan.c # 多 iov 偏移扫描
│ ├── g62_self.c # waiter 自触发 EDEADLK 测试
│ ├── g62_pispray.c # EDEADLK + slab spray + sched_setattr
│ ├── g62_rand.c # 写 randomize_va_space 测试
│ ├── gsu_v19.c # 8-iov + sched_setattr 触发
│ ├── gl_pselect*.c # pselect + sched_setattr 测试
│ ├── gl_scan.c # fd_set 偏移扫描
│ ├── sc64.c # shellcode payload
│ ├── trigger*.c # 原始触发 PoC (验证漏洞存在)
│ ├── ghostlock_root.c # 早期 root 尝试
│ └── test_*.c # 编译/运行测试
├── README.md
├── ghostlock64 # 8-iov 双 erase PoC 二进制
├── ghostlock63 # ghostlock 6.x 3-iov 二进制
├── g62_* # 3-iov 变种二进制
├── gl_* # pselect 测试二进制
├── gsu # sc-page hijack 变种
├── sc64 # shellcode
├── trigger* # 原始触发 PoC 二进制
└── test_* # 测试二进制
## 结论
**此内核版本 (5.4.161 ARM32) 的 PI 链实现不支持 GhostLock 的双 rb_erase 任意写技术。** 所有已知的 CVE-2026-43499 利用路线均在此设备上受阻。需要发现新的写 0 原语或其他漏洞才能继续。
## 作者的话
华为你阴死我了 烧了我deepseek V4 Pro 30RMB token