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

(Written entirely by DeepSeek, I know nothing about it) (Spent another few days tinkering, zero progress, gave up) (Currently can obtain root, but it's highly unstable; network drops after rooting, unplugging the cable triggers a reboot)

Device Bootloader 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 documents the complete process from "can it be exploited" to "how stable is it post-exploit".

Nature: Temporary root, invalidated upon reboot.

---

Disclaimer

This repository documents security research conducted on my own personal device, aimed at understanding the causes and stability boundaries of kernel PI race conditions.

• Contains no exploit binaries or directly runnable payloads —— payloads and frameworks are sourced from upstream public projects; this repository only references them, does not redistribute them.
• Does not provide tutorials for bypassing any specific vendor's protections, nor encourages use on unauthorized devices.
• Offsets and symbol addresses within the repository are only valid for the single kernel build listed here; switching kernels invalidates everything immediately.
• The relevant flaws have been fixed upstream (see below). The long-term value of this article lies in "the record itself" —— a real-world post-mortem of a race condition vulnerability under non-ideal conditions, including all its uncomfortable side effects.

---

0. One-Sentence Conclusion

The only viable path is:

CVE-2026-43499 (futex PI race write-what-where) + rt_sigreturn carrier
  → LD_PRELOAD injection into shell domain processes
  → Two-stage approach: first trigger SELinux Permissive, then overwrite task->real_cred / cred with init_cred
  → uid=0(root) context=u:r:kernel:s0, with su daemon implanted

But what's truly worth documenting isn't "how to get root" —— it's what happens after you get it.

You don't get a stable root; you get a "state that could detonate at any moment".

The exploit's write primitive will hang a forged rt_mutex_waiter onto a real futex PI chain, and the carrier for this waiter is a kernel stack / sprayed page that will be reused by subsequent syscalls. Thus, from the moment root is established, any system-level scheduling or priority change could trip over it, causing an immediate kernel panic and reboot. This isn't a bug; it's the inherent cost of this exploitation technique —— see docs/03 for details.

---

1. Applicability Boundaries (Entire scheme fails if mismatched)

Item	Value	Description
Model	Honor WIN RT, model AAK-AN00	Propagation name "Honor WIN RT"
SoC	Snapdragon 8 Elite SM8750-AB	Firmware not compatible with Honor WIN (AAP-AN00, SM8850-AC)
OS	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Hard requirement, character-for-character match
Kernel Config	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Prerequisite for carrier geometry
Firmware Package	.170	.160 / .175 untested
Bootloader	Permanently locked	No fastboot / no persistent su

Why the kernel version must be exact: The flaw was fixed in 6.6.140; our device runs 6.6.118 < 6.6.140 so it's still present; meanwhile, all kernel symbol addresses and "carrier geometry" for the exploit are anchored to this single build. Switching kernels immediately invalidates the offset table, and rollback is generally impossible.

---

2. Privilege Escalation Path Overview

┌─ Materials ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (extracted from device firmware)  │
│        ↓ Symbol resolution                                   │
│ target.h (kernel symbol addresses, byte-matched against kallsyms) │
│        ↓ Build                                               │
│ preload.so ──► Device-side /data/local/tmp/*.so              │
└─────────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD Injection
     ┌──────────── Two-Stage (Requires two separate processes) ─────┐
     │ Stage A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Stage B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1                │
     │          → task->real_cred ← &init_cred                       │
     │          → task->cred      ← &init_cred (completed by "pre-planted writer" process)│
     │          → setresuid(0,0,0) normalization                     │
     │          → Implant embedded su + daemon                       │
     └───────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Three critical points that must be done correctly (get it wrong and you'll hang or panic immediately):

1. Strict Ordering Rule: real_cred first, then cred. Reversing the order instantly grants full privileges and causes threads to go out of control.
2. There will inevitably be a transient state where cred ≠ real_cred between the two writes. At this point, any sched_setaffinity call will return EPERM → entire round hangs. The correct approach is to fork a "pre-planted writer" process (with clean credentials) before the first write; the parent process performs the first write, the writer performs the second, ensuring neither issues syscalls during the transient state.
3. Address model is independent of KASLR. The entire exploit relies solely on linear mapping aliases alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), stable across reboots; the so-called "slide phase" is actually for write primitive self-checks, not for bypassing KASLR.

Upstream framework: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Note this is not GhostLock —— GhostLock follows the pselect route, which does not match the waiter landing geometry for this build, see docs/06 for details.

---

3. Directory