GhostLock Exploitation Failure Summary on PD2229 (SM8475, 5.10.233 GKI)
I. Vulnerability and Device Facts
| Item | Value |
|---|
| Vulnerability Type | Stack Use-After-Free in the rt_mutex / futex PI path |
| Introduced Version | Linux 2.6.39-rc1 (May 2011, commit 8161239a8bcc) |
| Fixed Version | mainline 7.1 (commit 3bfdc63936dd), stable branches: 6.1.175 / 6.6.140 / 6.12.86 / 6.18.27 / 7.0.4 |
| Prerequisite | CONFIG_FUTEX_PI=y (enabled by default in mainstream kernels) |
| CVSS | 7.8 High |
| Exploit Stability | NebuSec original chain 97%, root in ~5 seconds |
| kernelCTF Bounty | $92,337 USD |
Affected kernel ranges:
- 2.6.39 ≤ Linux < 6.1.175 ✅ Affected
- 6.2 ≤ Linux < 6.6.140 ✅ Affected
- 6.7 ≤ Linux < 6.12.86 ✅ Affected
- 6.13 ≤ Linux < 6.18.27 ✅ Affected
- 6.19 ≤ Linux < 7.0.4 ✅ Affected
- Android GKI 5.10 is in none of the fix branches → PD2229's 5.10.233 is theoretically affected
1.2 PD2229 Device Measurements
II. Ideal Exploit Chain vs Actual PD2229 Progress
2.1 NebuSec Original Chain (successful on x86_64 / Pixel 10)
1. KASLR 绕过 → prefetch timing / PR_SET_MM_MAP auxv
2. UAF 触发 → 三线程 PI 依赖死锁 → FUTEX_CMP_REQUEUE_PI 返回 -EDEADLK
3. 栈回收 → PR_SET_MM_MAP 将 auxv 拷贝到 waiter 栈帧
4. rb_erase 受限写 → 覆写 inet6_protos[IPPROTO_UDP]
5. CEA + ROP → 控制流劫持
6. core_pattern 翻转 → root shell (97% 成功率)
2.2 Actual PD2229 Progress by Stage
III. Stack Reclaim Primitive Exhaustive Search Results (PD2229 Measured)
3.1 Key Stack Frame Layout Calculations
futex 路径总深度:
__arm64_sys_futex 0x90
+ do_futex 0xc0
+ futex_wait_requeue_pi 0x1b0
= 0x300
waiter 位置 = SYS_SP - 0x300 + 0x20 = SYS_SP - 0x2e0
pselect 路径:
core_sys_select 栈帧 0x1c0, stack_fds 在 sp+0x50
覆盖区间: SYS_SP - 0x1c0 + 0x50 = SYS_SP - 0x170 起
与 waiter (SYS_SP - 0x2e0) 差距 0x170 (368 字节) → 不重叠
3.2 17 Stack Write Methods Attempted
17/17 all failed.
3.3 Root Cause of Failure
The stack layout produced by PD2229's SM8475 5.10 GKI compiler (PGO + LTO + BOLT) causes core_sys_select's stack_fds and futex_wait_requeue_pi's rt_mutex_waiter to be architecturally non-overlapping. This is an objective fact determined by the compiler, not an exploit technique issue.
The JoinChang repository explicitly states: "The pselect stack overlay only works when the freed rt_mutex_waiter lands within the user-controllable region of the stack_fds buffer" — PD2229 does not satisfy this condition.
IV. Public Reference Repository Comparative Analysis
NebuSec/CyberMeowfia — Original Exploit Framework
- Repository: https://github.com/NebuSec/CyberMeowfia
- Target: x86_64 Linux / Pixel 10 (6.x GKI)
- Stack Reclaim:
PR_SET_MM_MAP copies auxv to the kernel stack
- Success Rate: 97%, root [shell] in ~5 seconds
- PD2229 Applicability: ❌
PR_SET_MM_MAP is blocked by EPERM on Android
JoinChang/ghostlock-oneplus — OnePlus locked-BL jailbreak
- Repository: https://github.com/JoinChang/ghostlock-oneplus
- Verified Devices:
- OnePlus Ace 6T (PLR110, SM8845) — 6.12.38 GKI ✅
- OnePlus 15 (PLK110, SM8845) — 6.12.23 GKI ✅
- Technical Highlights:
- Offset auto-extraction: kallsyms (28) + BTF (57) + derived (9) + constants (12) = 103/103
- pselect stack overwrite, SP diff = -64
PSELECT_SHIFT = -2
- Exploit chain: futex UAF → forge waiter → pselect controls the stack → rb_erase constrained write → selinux_state.enforcing=0 → overwrite cred with init_cred
- Explicitly declared infeasible: "Not Feasible (stack layout incompatible)" — only applies to kernels where pselect stack_fds overlaps the waiter
- PD2229 Applicability: ❌ Kernel generation mismatch (6.12 vs 5.10), and stack layouts do not overlap
p2p3p/GhostLock-for-OnePlus — Complete OnePlus 6.12 Exploit
YuKongA/ghostlock-oplus — OPPO Find N5/X8
OPPO Find X6 Pro (PGEM10) Adaptation — 5.15.149
- Device: SM8550, 5.15.149-android13, Android 15
- Progress: ✅ KASLR bypass (perf_event_open + callchain sampling); later stages not publicly disclosed as a complete exploit
- Significance: Proves KASLR bypass is feasible on 5.15 GKI, but the stack reclaim stage has not been publicly verified
pubglite55/oppo-ghostlock — OPPO Find N2
- Repository: https://github.com/pubglite55/oppo-ghostlock
- Device: OPPO Find N2 (CPH2413, SM8475)
- Kernel: 5.10.236-android12-9-o-g74d132f4467a
- Android: 16 (BP2A.250605.015)
- Implemented:
- ✅ Firefox CVE-2026-10702 AAW (Stage 1)
- ✅ KASLR bypass (direct kaslr_base computation)
- ✅ GhostLock FUTEX trigger (FUTEX_CMP_REQUEUE_PI ret=0)
- ✅ KernelSnitch mm_struct leak
- ✅ sk_buff heap spray (4/4 sends successful)
- ✅ IDA Pro verification of 70+ offsets
- Core Blocker:
"pselect cannot manipulate the waiter structure — with NFDS >336 the fd_set is on the heap; configfs/ashmem unsupported (ashmem SET_NAME is truncated); all other kernel write paths are blocked (/proc/self/mem, /dev/mem, binder)"
- Relation to PD2229: Same platform, same generation (SM8475, 5.10.236 vs 5.10.233), only 3 minor versions apart, faces exactly the same architectural limitations
harry1080/oppo-ghostlock — OPPO Find N2
- Repository: https://github.com/harry1080/oppo-ghostlock
- Device: OPPO Find N2 (CPH2413, SM8475)
- Kernel: 5.10.236-android12-9-o-g74d132f4467a
- Android: 16 (BP2A.250605.015)
- Public Community Statement:
"In the exploitable pixel10 version, pselect's stack_fds happens to overlap rt_waiter on the kernel stack — this part is actually the most troublesome. On the OPPO Find N2 kernel, the stack regions of these two calls do not overlap at all, or the overlap is uncontrollable. You have to find another way to control the stack, switching to other syscalls with controllable kernel stacks to build the stack. Simply adapting offsets can never succeed — OPPO's rt_waiter does not overlap pselect's stack_fds at all"
- Relation to PD2229: Same SM8475 5.10 GKI as PD2229, conclusion fully applies
4.3 Reference Repository Comparison Summary Table
V. Key Kernel Symbols and Offsets (Measured on PD2229 vmlinux)
Static base 0xffffffc008000000; add the KASLR slide at runtime.
rt_mutex_waiter Structure (vivo 5.10.233 custom)
struct rt_mutex_waiter {
uint64_t private; // +0x00 (vivo 私有字段)
struct rb_node {
uint64_t rb_parent_color; // +0x08
uint64_t rb_right; // +0x10 (vivo 调换顺序)
uint64_t rb_left; // +0x18
} tree;
struct task_struct *task; // +0x20
struct rt_mutex *lock; // +0x28
};
// 总大小 0x30 (48 字节)
VI. Implemented vs. Required
✅ Implemented Infrastructure
- KASLR Bypass —
perf_event_open + callchain sampling (same method as OPPO Find X6 Pro 5.15.149)
- UAF Trigger — three-thread PI deadlock, FUTEX_CMP_REQUEUE_PI returns -EDEADLK
- Complete Symbol Table — 103+ symbols verified via IDA (following JoinChang's 103/103 extraction methodology)
- rt_mutex_waiter Structure Layout — vivo custom offsets confirmed
- Precise Stack Frame Layout Analysis — depth calculations completed for the futex and pselect/io_uring paths
- Exhaustive Exclusion of 17 Stack Reclaim Candidates — complete "infeasible" matrix established
❌ Not Implemented (Core Block)
- Stack Reclaim Primitive — architecturally unavailable due to the SM8475 5.10 GKI compiler's stack layout
- Constrained Write Primitive — rb_erase cannot be triggered because stack reclaim failed
- All Subsequent Stages — cascading block
VII. Final Conclusion
⚠️ GhostLock (CVE-2026-43499) is not exploitable on the PD2229 (vivo X Fold+, SM8475, 5.10.233 GKI, Android 15 OriginOS 5).
The root cause is that the stack layout produced by the SM8475 5.10 GKI compiler (PGO+LTO+BOLT) makes the stack frames of all known syscalls architecturally non-overlapping with the rt_mutex_waiter. This is an objective fact determined by the compiler, not an exploit technique issue.
All successful exploit cases are on 6.6/6.12 GKI, because the compiler output of these newer kernels makes pselect's fd_set perfectly overlap the waiter (SP diff=-64). 5.10 GKI does not have this property.
Established Infrastructure
- ✅ KASLR bypass primitive (perf_event_open side channel)
- ✅ 103+ kernel symbols and offsets
- ✅ rt_mutex_waiter structure layout
- ✅ UAF trigger capability
- ✅ Exclusion matrix for 17 stack reclaim candidates
IX. Reference Repository Index