CVE-2026-43499 · Honor WIN RT (AAK-AN00) Temporary Root Research Notes

(All written by deepseek, I don't understand anything) (After several more days of tinkering, progress is zero, giving up) (Currently root can be obtained, but it's very unstable; after rooting the network drops, and unplugging the cable causes a reboot) (All conclusions in this repository apply only to Honor WIN RT, CVE-2026-43499 vulnerability, 6.6.118-android15-8-gf17133276a57-abogki518694926-4k kernel. Do not extend the conclusions to temporary root; temporary root can persist and run relatively stably)

The device Bootloader is permanently locked (ro.oem_unlock.supported is empty), no fastboot, no persistent su, no Magisk. The only remaining path is a kernel vulnerability. This repository records the complete process from "can it be exploited" to "how stable is it really after exploitation."

Nature: temporary root, invalidated on reboot.

---

Disclaimer

This repository records a security research process conducted on my own device, with the goal of understanding the causes and stability boundaries of the kernel PI race condition.

• Contains no exploit binaries or directly runnable exploit payloads — the payload and framework come from upstream public projects; this repository only references them, does not redistribute them.
• Does not provide tutorials for bypass methods targeting any specific vendor, and does not encourage use on unauthorized devices.
• The offsets and symbol addresses in this repository are valid only for the single kernel build listed in this document; changing the kernel invalidates all of them.
• The relevant defects have been fixed upstream (see below). The long-term value of this document lies in "this record itself" — a real-world, under non-ideal conditions, practical retrospective of a race condition vulnerability, including all its uncomfortable side effects.

---

0. One-sentence conclusion

The only path that worked is:

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 守护进程

But what is truly worth writing down is not "how to get root"—it is what happens after you get it.

What you get is not a stable root, but a "state that could be detonated at any moment."

The exploit's write primitive hooks a forged rt_mutex_waiter into the real futex PI chain, and the carrier of this waiter is a kernel stack / sprayed page that will be reused by subsequent system calls. So from the moment root lands, any system-level scheduling or priority change may step on it, causing an immediate kernel panic and reboot. This is not a bug; it is the inherent cost of this exploitation technique — see docs/03 for details.

---

1. Applicable Boundaries (if not met, the entire scheme is void)

Item	Value	Description
Device	HONOR WIN RT, model AAK-AN00	Marketing name "HONOR WIN RT"
SoC	Snapdragon 8 Elite SM8750-AB	Firmware is not interchangeable with HONOR WIN (AAP-AN00, SM8850-AC)
System	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Hard requirement, character-by-character match
Kernel config	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Prerequisite for the carrier geometry
Firmware package	.170	.160 / .175 not tested
Bootloader	Permanently locked	No fastboot / no persistent su

Why the kernel version must be pinned exactly: the flaw was fixed in 6.6.140, and this device's 6.6.118 < 6.6.140, so it is still present; at the same time, all of the exploit's kernel symbol addresses and the "carrier geometry" are anchored to this one build. After changing the kernel, the offset table is immediately invalid, and generally cannot be rolled back.

---

2. Overview of the Privilege Escalation Path

┌─ 材料 ────────────────────────────────────────────────┐
│ 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

Three things that must be done right (get them wrong and you either get stuck or panic outright):

1. Iron rule of ordering: real_cred first, then cred. Reversing the order instantly grants full privileges and the thread goes out of control.
2. Between the two writes there is inevitably a transient state where cred ≠ real_cred. At that moment any sched_setaffinity returns EPERM → the whole round deadlocks. The correct approach is to fork the "pre-placed writer" process before the first write (with clean credentials); the parent process performs the first write, the writer performs the second write, and neither issues a syscall while in the transient state.
3. The address model is independent of KASLR. The entire exploit only uses the linear-mapping alias alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), which is stable across reboots; the real value of the so-called "slide phase" is self-verification of the write primitive, not bypassing KASLR.

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

---

3. Directory