CVE-2026-43499 · 荣耀 WIN RT (AAK-AN00) 临时 Root 研究笔记

（全是deepseek写的，我啥也不懂）

设备 Bootloader 永久锁死（ro.oem_unlock.supported 为空），没有 fastboot、没有持久 su、没有 Magisk。 唯一还能走的路是内核漏洞。本仓库记录从「能不能打」到「打完之后到底有多稳」的完整过程。

性质：临时 root，重启即失效。

免责声明

本仓库记录的是在本人自有设备上进行的安全研究过程，目的是理解内核 PI 竞态的成因与稳定性边界。

• 不包含任何 exploit 二进制或可直接运行的利用载荷 —— 载荷与框架来自上游公开项目，本仓库只引用、不转发。
• 不针对任何特定厂商的绕过手段提供教程，不鼓励在非授权设备上使用。
• 仓库内的偏移、符号地址只对本文列出的那一个内核 build 有效，换内核即全部作废。
• 相关缺陷在 upstream 已修复（见下）。本文的长期价值在于「这份记录本身」—— 一个真实的、非理想条件下的竞态漏洞实战复盘，包括它所有让人不舒服的副作用。

0. 一句话结论

唯一走通的路径是：

CVE-2026-43499（futex PI 竞态 write-what-where） + rt_sigreturn 载波
  → LD_PRELOAD 注入 shell 域进程
  → 两段式：先打 SELinux Permissive，再改 task->real_cred / cred 为 init_cred
  → uid=0(root) context=u:r:kernel:s0，并植入 su 守护进程

但真正值得写下来的不是「怎么拿到 root」——是拿到之后发生的事。

拿到的不是一个稳定的 root，而是一个「随时可能被引爆的状态」。

exploit 的写原语会把伪造的 rt_mutex_waiter 挂进真实的 futex PI 链， 而这个 waiter 的载体是会被后续系统调用复用的内核栈 / 喷射页。 于是从 root 落地那一刻起，任何一次系统级调度或优先级变动都可能踩到它，直接内核 panic 重启。 这不是 bug，是这套利用手法的固有代价 —— 详见 docs/03。

1. 适用边界（不符则整个方案作废）

为什么必须卡死内核版本：缺陷在 6.6.140 修复，本机 6.6.118 < 6.6.140 所以还在； 同时 exploit 的所有内核符号地址与「载波几何」都锚定在这一个 build 上，换内核之后偏移表立即作废，且一般不可回退。

2. 提权路径全景

┌─ 材料 ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf（自设备固件提取）            │
│        ↓ 符号解析                                       │
│ target.h（内核符号地址，已与 kallsyms 逐字节核对）      │
│        ↓ 构建                                           │
│ preload.so ──► 设备端 /data/local/tmp/*.so             │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD 注入
     ┌──────────── 两段式（必须两个独立进程）────────────┐
     │ 阶段 A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ 阶段 B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred（由"预置写手"进程完成）│
     │         → setresuid(0,0,0) 正规化                           │
     │         → 植入内嵌 su + daemon                              │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

三个必须做对的地方（做错就卡死或者直接 panic）：

1. 顺序铁律：先 real_cred，后 cred。 反序会瞬间满权限、线程失控。
2. 两刀之间必然存在 cred ≠ real_cred 的瞬态。 此时任何 sched_setaffinity 都会 EPERM → 整轮卡死。 正解是在第一刀之前就 fork 出「预置写手」进程（凭据干净），父进程写第一刀、写手写第二刀，谁都不在瞬态里发 syscall。
3. 地址模型与 KASLR 无关。 整套利用只走线性映射别名 alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ)，跨重启稳定； 所谓 "slide 阶段" 的真实价值是写原语自检，不是绕 KASLR。

上游框架：Linuxoid-cn/CVE-2026-43499-Poc-Analysis。 注意这不是 GhostLock —— GhostLock 走 pselect 路线，与本 build 的 waiter 落点几何不匹配， 详见 docs/06。

3. 目录

4. 时间线

5. 一句话给后来者

如果你也在打一个 BL 锁死的机型，请先想清楚你拿 root 要做什么， 因为在这类机型上 root 很可能是一个只能用十几分钟的窗口。 把「需要 root 且能跨重启保留」的操作列成清单，一次跑完，然后 reboot 回干净态。 不要试图「消除副作用」—— 那是手法本身的代价。