Locked-bootloader root on Redmi K70 Pro (manet, kernel 6.1.118): working temp-root via mqsas, and where persistent root got stuck

[jiusi1-cpu]

TL;DR

A vendor-left injection channel gives working temporary root on the Redmi K70 Pro (locked bootloader). Persistent root is not achieved — this post documents exactly where it got stuck, in case it's useful to others on the same kernel.

• Device: Redmi K70 Pro (manet / 23117RK66C / SM8650)
• OS: HyperOS OS3.0.9.0.WNMCNXM
• Kernel: 6.1.118-android14-11-gca0ef6d17716-ab13624819, KMI android14-6.1, +pgo,+bolt,+lto
• Bootloader: LOCKED (ro.boot.flash.locked=1, sys.oem_unlock_allowed=0)
• Root: KernelSU ksud 3.1.0-29-gf0615d3c, injected via late-load

---

1. Working temporary root (not an exploit — a vendor channel)

fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
fastboot continue
# wait for sys.boot_completed=1, then immediately:
service call miui.mqsas.IMQSNative 21 \
  i32 1 s16 '/data/local/tmp/ksud' \
  i32 1 s16 'late-load' \
  s16 '/data/local/tmp/ksulog.txt' i32 120

The injected process lands as uid=0(root) gid=1000(system) context=u:r:hypsys_ssi_default:s0.

Constraints worth knowing:

• Injection only works while SELinux is Permissive. ro.boot.selinux reads back enforcing even when the fastboot arg was passed — use getenforce, not the prop.
• The injected late-load runs module service.sh, and those scripts commonly flip SELinux back to Enforcing (e.g. if Permissive then setenforce 1). You get one shot.
• Permissive window measured: stable ≥ 50 s after boot.
• Reboot loses root; re-running the recipe is 100% reproducible and does not touch data.

---

2. Where persistent root got stuck

2.1 HyperOS blocks framework interfaces even as root

In domain u:r:su:s0, with uid=0 and CapEff=000001ffffffffff:

am force-stop ...   → Failed transaction (2147483646)
pm list packages    → Failed transaction (2147483646)
cmd appops ...      → Failed transaction (2147483646)
settings get/put    → Failed transaction (2147483646)

Dropping to su 2000 doesn't help — the context is still u:r:su:s0.

⇒ after escalation you cannot use framework APIs at all. Only kernel/sysfs nodes, direct PID kills, and dumpsys (read) remain useful. Worth knowing if you plan to do post-exploitation setup from service.sh.

2.2 Some of the sysfs nodes KernelSU-style tuners write are read-only

Resolved from the Joyose cloud config (/data/data/com.xiaomi.joyose/databases/teg_config.db), Xiaomi writes these itself:

Node	Perm
policy{0,2,5,7}/walt/target_load_thresh	-r--r--r--
policy{0,2,5,7}/walt/target_loads	-r--r--r--
policy{0,2,5,7}/walt/hispeed_freq	-r--r--r--
policy{0,2,5,7}/walt/pl, rtg_boost_freq	-rw-r--r-- ✅

Even as root, writing the 0444 sysfs nodes fails with Permission denied. Any module that writes those is silently doing nothing. The writable levers here were /proc/sys/walt/sched_fmax_cap, kgsl-3d0/max_gpuclk, and several /sys/module/migt/parameters/* entries.

2.3 A locked-bootloader kernel UAF route, and the wall it hit

Explored CVE-2026-43499 (futex PI stack UAF) as a path to persistent root. Feasibility pre-check passed (__arm64_sys_futex → bl do_futex → bl futex_wait_requeue_pi, none LTO-inlined), and stack geometry worked out:

T0 = SP0 - 0x1E8      (rt_mutex_waiter base)
SP0 = SP at entry to any __arm64_sys_* (all syscalls blr from the same site)

CONFIG_RANDOMIZE_KSTACK_OFFSET is compiled in but off by default (static key initial 0), so the geometry is deterministic.

Two independent findings that may be useful to others:

Published rt_mutex_waiter offsets appear wrong for this build. Measured layout (3 independent disassembly proofs):

Field	Published	Measured
pi_tree_entry	+0x28	+0x18
task	+0x50	+0x30
lock	+0x58	+0x38
prio	+0x40	+0x44
deadline	+0x48	+0x48

Key evidence — one stp writes both pointers:

; task_blocks_on_rt_mutex @ 0xffffffc008fff054
0xffffffc008fff0b0  stp x20, x19, [x21, #0x30]   ; x20=task, x19=lock, x21=waiter
; rt_mutex_adjust_prio_chain @ 0xffffffc008fffc88
0xffffffc008fffd34  sub x8, x8, #0x18             ; pi_waiters rb_entry => pi_tree @ +0x18

Laying data out against +0x58 would silently misalign.

Hard threshold that prunes candidates cheaply. With D = stack depth from syscall entry to the copy site and off_b = buffer offset in the frame (off_b ≥ 0):

delta = D - off_b >= 0x210   (measured offsets: 0x1D0)
⇒ D >= 0x210 (528 bytes) is an absolute necessary condition

Any syscall carrier shallower than that is structurally out, no matter the buffer size. Three carriers passed (rt_sigreturn fpsimd restore at SP0-0x280, ashmem ASHMEM_SET_NAME ioctl at SP0-0x228, sendmsg at SP0-0x1C8).

The blocker: 6.1 core_sys_select uses kvmalloc_node for the fd bitmap — heap, not stack — so the pselect-style stack overlay can't reach the freed waiter, and the res_* stack buffers used by the SLIDE_PSELECT_RES_ENCODE route don't exist in this kernel.

The unsolved core: geometry says a buffer can overlap the waiter, but nothing yet shows the kernel will dereference the overwritten slot inside the free/reuse window. That distinction is the whole game, and it's where this stopped.

---

3. Why post this here

Two reasons:

1. The am/pm/appops/settings block in u:r:su:s0 is a post-exploitation constraint that module authors on HyperOS/ColorOS builds will run into, and it's not obvious until you hit it.
2. The read-only walt/* sysfs discovery means some commonly-copied tuning writes are no-ops. If a module relies on them, that's a silent failure worth checking.

---

Full write-up (device facts, geometry derivation, carrier list, dead ends, open questions):

https://github.com/jiusi1-cpu/manet-persistent-root-research

Includes an English README. Happy to provide kernel disassembly dumps for any of the addresses above. If any of this is already known for 6.1 GKI, feel free to correct me — that's the main reason for posting.