Forschungsnotizen und PoC-Entwicklung für CVE-2026-43499 (GhostLock) Kernel-UAF auf vivo Y200i Android 14, einschließlich futex-PI-Chain-Stack-Reclaim-Primitiven und Frame-Layout-Grenzen.
Gerät: vivo Y200i (PD2354C), Snapdragon 4 Gen 2 (SM4450), Android 14 / OriginOS 4 Kernel: 5.10.218-gki-g3a51ea9d5834 (39-Bit VA, 4K-Seiten, KASLR an, STACKLEAK=y, kein SVE)
Ziel: temporärer Root via CVE-2026-43499 (GhostLock).
Bisher funktionierend:
Blockiert: Das Stack-Reclaim-Primitiv kann den rb_node des rt_mutex_waiter nicht erreichen.
Schlüsselzahlen (identisch über zwei unabhängige Firmware-Pakete):
__arm64_sys_futex 0xe0
do_futex 0xc0 (NICHT inlined - ein bl do_futex existiert)
futex_wait_requeue_pi 0x1b0 (waiter bei sp+0x20)
=> futex-Kettentiefe T0-0x330
__arm64_sys_pselect6 0xa0 core_sys_select 0x1c0 (fd_set bei sp+0x50) => pselect-Kettentiefe T0-0x210, kontrollierbares Fenster nur 120 Bytes => Lücke 0x120, architektonisch nicht überlappend
waiter-Layout (5.10 kompakt, entspricht PFEM10): +0x18 pi_tree_entry.__rb_parent_color <- was rt_mutex_adjust_prio_chain durchläuft +0x20 pi_tree_entry.rb_right +0x28 pi_tree_entry.rb_left +0x30 task +0x38 lock +0x40 prio +0x48 deadline
Belege aus 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)
Da copy_from_user in Richtung höherer Adressen schreibt, erfordert das Abdecken von pi_tree_entry, dass die Copy-Basis <= T0-0x318 ist.
Erschöpfte Pfade: pselect6/core_sys_select T0-0x210 -> fehlen 0x120 poll/do_sys_poll Fenster endet T0-0x344, max 0xf0B (N_STACK_PPS=30) -> fehlen 0x14 rt_sigreturn (fpsimd) T0-0x300 -> erreicht nur waiter+0x30 rt_sigreturn (SVE) T0-0x310 -> würde waiter+0x10 abdecken, aber diese CPU hat kein SVE; Kernel lehnt SVE- sigframe-Datensätze mit -EINVAL ab compat rt_sigreturn / vfp T0-0x2c0 -> noch flacher
Vollständiger Kernel-Scan aller copy_from_user-Stellen: 655 insgesamt, 118 erreichbar, max. Tiefe 0x300 (bpf_prog_get_info_by_fd, ebenfalls durch CAP_BPF beschränkt). Benötigt 0x318.
Fazit: Die Stack-Geometrie dieses Kernels ist auf 0x300 für stack-basiertes copy_from_user begrenzt; das Abdecken von pi_tree_entry erfordert 0x318. Kein Tuning-Problem - es ist ein Compile-Zeit-Frame-Layout-Unterschied. do_futex ist hier nicht inlined, anders als PFEM10 (5.10.236, Clang 12.0.5), höchstwahrscheinlich ein anderes Inlining-Kostenmodell.
Gesucht:
