## https://sploitus.com/exploit?id=CE15A0A4-9CA2-52DA-94D3-C40A5206ABA9
# CVE-2026-43499 · Honor WIN RT (AAK-AN00) Temporary Root Research Notes
(All written by deepseek; I don’t know anything about this.)
> The device’s bootloader is **permanently locked** (`ro.oem_unlock.supported` is empty); there is no fastboot, no persistent `su`, and no Magisk.
> The only viable path left is a kernel vulnerability. This repository documents the entire process, from “Can it be exploited?” to “How stable is it after exploitation?”
**Nature: Temporary root; expires upon reboot.**
---
## Disclaimer
This repository documents the security research process conducted on **my own personal device**, with the goal of understanding the causes and stability limits of kernel PI race conditions.
- **Does not contain any exploit binaries or directly executable payloads** — the payloads and frameworks come from publicly available upstream projects; this repository only references them and does not redistribute them.
- Does not provide tutorials on bypass methods targeting any specific manufacturer, and does not encourage use on unauthorized devices.
- The offsets and symbol addresses in this repository **are valid only for the specific kernel build listed in this article**; they become invalid if the kernel is changed.
- The relevant vulnerabilities have been fixed in upstream (see below). The long-term value of this article lies in “**this record itself**”—
a real-world post-mortem analysis of a race condition vulnerability under non-ideal conditions, including all its unpleasant side effects.
---
## 0. One-Sentence Conclusion
The only successful approach is:
```
CVE-2026-43499 (futex PI race condition: write-what-where) + rt_sigreturn as the carrier
→ LD_PRELOAD injection into a shell-domain process
→ Two-step process: First exploit SELinux Permissive mode, then modify `task->real_cred` / `cred` to `init_cred`
→ uid=0 (root) context=u:r:kernel:s0, and plant a `su` daemon
```
But what’s truly worth noting isn’t “how to gain root”—**it’s what happens after gaining root**.
> **What you gain isn’t stable root access, but a “state that could be triggered at any moment.”**
>
> The exploit’s code injects a **falsified `rt_mutex_waiter` into the real futex PI chain**,
> and this waiter is hosted on **kernel stack or injected pages that will be reused by subsequent system calls**.
> Consequently, from the moment root access is obtained, any instance of **system-level scheduling or priority changes** may trigger it, causing an immediate kernel panic and reboot.
> This is not a bug, but rather the **inherent cost** of this exploitation technique — see [`docs/03`](docs/03-True-Cause-of-Stability-PI-Chain-Residue.md) for details.
---
## 1. Applicability Boundaries (If any condition is not met, the entire approach is invalid)
| Item | Value | Description |
|---|---|---|
| Device Model | Honor WIN RT, model **AAK-AN00** | Marketing name “Honor WIN RT” |
| SoC | Snapdragon 8 Ultra **SM8750-AB** | **Not compatible with** Honor WIN (AAP-AN00, SM8850-AC) firmware |
| OS | Android 16 / MagicOS 10 | — |
| **Kernel** | **`6.6.118-android15-8-gf17133276a57-abogki518694926-4k`** | ★ Hard requirement; must match character by character |
| Kernel Configuration | 4K pages, `VA_BITS=39`, `CONFIG_FUTEX_PI=y` | Carrier geometry prerequisite |
| Firmware Package | `.170` | `.160` / `.175` not tested |
| Bootloader | Permanently locked | No fastboot / No persistent su |
**Why the kernel version must be locked**: The bug was fixed in `6.6.140`; this device runs `6.6.118 real_cred ← &init_cred │
│ → task->cred ← &init_cred (performed by the "pre-installed writer" process) │
│ → setresuid(0,0,0) normalization │
│ → Inject embedded su + daemon │
└─────────────────────────────────────────────────────────────┘
↓
uid=0(root) context=u:r:kernel:s0
```
Three critical steps that must be done correctly (failure will result in a deadlock or an immediate panic):
1. **Ironclad rule of order: `real_cred` first, then `cred`.** Reversing the order will instantly grant full privileges and cause the thread to run amok.
2. **There must be a transient state between the two calls where `cred ≠ real_cred`.** At this point, any `sched_setaffinity` call will result in an EPERM error → causing the entire round to freeze.
The correct approach is to **fork a “pre-configured writer” process** before the first write (with clean credentials). The parent process performs the first write, and the writer performs the second; neither makes a syscall during the transient state.
3. **The address model is independent of KASLR.** The entire exploit relies solely on a linear mapping alias:
`alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ)`, which remains stable across reboots;
The true value of the so-called “slide phase” lies in **write-primitive self-checking**, not in bypassing KASLR.
> Upstream framework: `Linuxoid-cn/CVE-2026-43499-Poc-Analysis`.
> **Note: This is not GhostLock** — GhostLock uses the `pselect` approach, which geometrically does not align with the waiter’s landing point in this build;
> see [`docs/06`](docs/06-dead-end-list.md) for details.
---
## 3. Table of Contents
| Document | Content |
|---|---|
| [01 · Feasibility Analysis](docs/01-Feasibility-Analysis.md) | Why `rt_sigreturn` is the only remaining carrier |
| [02 · Privilege Escalation Chains and Success Factors](docs/02-Privilege-Escalation-Chains-and-Success-Factors.md) | Write primitives, six-step chains, pre-set writers, success criteria |
| [03 · True Cause of Stability: PI Chain Residuals](docs/03-True-Cause-of-Stability-PI-Chain-Residuals.md) | ★ Core. Network disconnection is not a network disconnection—it’s a panic; includes disassembly of crash points |
| [04 · PC-Free Channel: Shizuku](docs/04-PC-Free-Channel-Shizuku.md) | Use Shizuku’s `rish` to replace `adb` for launching the exploit |
| [05 · KernelSU’s late-load](docs/05-KernelSU-late-load.md) | How LKM is activated and why it’s the most dangerous trigger |
| [06 · Dead-End List](docs/06-Dead-End-List.md) | Paths I’ve tried but found to be dead ends, to save others from retrying |
| [07 · Pitfalls and Environment](docs/07-Pitfalls-and-Environment.md) | Traps in the script environment for retrieving panic stacks without root |
| [tools/](tools/) | Reusable scripts (redacted, generic version) |
---
## 4. Timeline
| Date | Progress |
|---|---|
| 09-08 | Confirmed BL is permanently locked; OEM unlock channel has been removed ⇒ Abandoned the official route; switched to the exploit route |
| 09-09 | Breached the manufacturer’s after-sales firmware repository, obtained `boot.img`, and extracted the kernel and symbols |
| 09-10 | Carrier search converged on `rt_sigreturn`; **Privilege escalation successful (20:14)**, `uid=0` |
| 09-11 | Established a PC-free method (Shizuku); KernelSU can be activated; **Determined the true cause of “network disconnection” = residual PI chain** |
---
## 5. A Word of Advice for Future Attempters
> If you’re also working on a BL-locked device, please **first think carefully about what you intend to do with root access**,
> because on these devices, root access is likely a **window that lasts only about ten minutes**.
> Make a list of operations that “require root access and must persist through reboots,” complete them all at once, and then `reboot` to return to a clean state.
> Don’t try to “eliminate side effects”—that’s simply the cost of the method itself.