Research notes and PoC development for CVE-2026-43499 (GhostLock) kernel UAF on vivo Y200i Android 14, covering futex PI-chain stack-reclaim primitives and frame-layout limits.
Device: vivo Y200i (PD2354C), Snapdragon 4 Gen 2 (SM4450), Android 14 / OriginOS 4 Kernel: 5.10.218-gki-g3a51ea9d5834 (39-bit VA, 4K pages, KASLR on, STACKLEAK=y, no SVE)
Goal: temporary root via CVE-2026-43499 (GhostLock).
Working so far:
Blocked: the stack-reclaim primitive cannot reach the rt_mutex_waiter's rb_node.
Key numbers (identical across two independent firmware packages):
__arm64_sys_futex 0xe0
do_futex 0xc0 (NOT inlined - a bl do_futex exists)
futex_wait_requeue_pi 0x1b0 (waiter at sp+0x20)
=> futex chain depth T0-0x330
__arm64_sys_pselect6 0xa0 core_sys_select 0x1c0 (fd_set at sp+0x50) => pselect chain depth T0-0x210, controllable window only 120 bytes => gap 0x120, architecturally non-overlapping
waiter layout (5.10 compact, matches PFEM10): +0x18 pi_tree_entry.__rb_parent_color <- what rt_mutex_adjust_prio_chain walks +0x20 pi_tree_entry.rb_right +0x28 pi_tree_entry.rb_left +0x30 task +0x38 lock +0x40 prio +0x48 deadline
Evidence from rt_mutex_adjust_prio_chain: ldr x8, [task, #0x888] ; task->pi_waiters.rb_leftmost sub x8, x8, #0x18 ; rb_entry(node, rt_mutex_waiter, pi_tree_entry)
Since copy_from_user writes toward higher addresses, covering pi_tree_entry requires the copy base to be <= T0-0x318.
Exhausted paths: pselect6/core_sys_select T0-0x210 -> short by 0x120 poll/do_sys_poll window ends T0-0x344, max 0xf0B (N_STACK_PPS=30) -> short by 0x14 rt_sigreturn (fpsimd) T0-0x300 -> only reaches waiter+0x30 rt_sigreturn (SVE) T0-0x310 -> would cover waiter+0x10, but this CPU has no SVE; kernel rejects SVE sigframe records with -EINVAL compat rt_sigreturn / vfp T0-0x2c0 -> shallower still
Full-kernel scan of all copy_from_user sites: 655 total, 118 reachable, max depth 0x300 (bpf_prog_get_info_by_fd, also gated by CAP_BPF). Need 0x318.
Conclusion: this kernel's stack geometry caps at 0x300 for stack-based copy_from_user; covering pi_tree_entry needs 0x318. Not a tuning issue - it is a compile-time frame-layout difference. do_futex is not inlined here, unlike PFEM10 (5.10.236, Clang 12.0.5), most likely a different inlining cost model.
Looking for:
