Riepilogo del fallimento dello sfruttamento di GhostLock su PD2229 (SM8475, 5.10.233 GKI)

一、Fatti relativi alla vulnerabilità e al dispositivo

1.1 Informazioni di base su CVE-2026-43499 (GhostLock)

Intervallo di kernel interessati:

• 2.6.39 ≤ Linux < 6.1.175 ✅ Interessato
• 6.2 ≤ Linux < 6.6.140 ✅ Interessato
• 6.7 ≤ Linux < 6.12.86 ✅ Interessato
• 6.13 ≤ Linux < 6.18.27 ✅ Interessato
• 6.19 ≤ Linux < 7.0.4 ✅ Interessato
• Android GKI 5.10 non incluso in alcun ramo di correzione → il 5.10.233 di PD2229 teoricamente interessato

1.2 Test effettivi sul dispositivo PD2229

二、Catena di sfruttamento ideale vs progresso effettivo su PD2229

2.1 Catena originale NebuSec (x86_64 / Pixel 10 riuscita)

1. Bypass KASLR        → prefetch timing / PR_SET_MM_MAP auxv
2. Trigger UAF         → deadlock di dipendenza PI a tre thread → FUTEX_CMP_REQUEUE_PI restituisce -EDEADLK
3. Riciclo stack       → PR_SET_MM_MAP copia auxv nel frame dello stack del waiter
4. Scrittura limitata rb_erase   → sovrascrive inet6_protos[IPPROTO_UDP]
5. CEA + ROP           → dirottamento del flusso di controllo
6. Inversione core_pattern → shell root (tasso di successo 97%)

2.2 Progresso effettivo di ciascuna fase su PD2229

三、Risultati dell'enumerazione esaustiva della primitiva di riciclo stack (test effettivi su PD2229)

3.1 Calcoli chiave del layout dello stack frame

Profondità totale del percorso futex:
  __arm64_sys_futex    0x90
  + do_futex           0xc0
  + futex_wait_requeue_pi  0x1b0
  = 0x300
Posizione waiter = SYS_SP - 0x300 + 0x20 = SYS_SP - 0x2e0

Percorso pselect:
  stack frame core_sys_select 0x1c0, stack_fds a sp+0x50
  Intervallo di copertura: a partire da SYS_SP - 0x1c0 + 0x50 = SYS_SP - 0x170
  Differenza dal waiter (SYS_SP - 0x2e0) di 0x170 (368 byte) → nessuna sovrapposizione

3.2 17 metodi di scrittura stack tentati

17/17 tutti falliti.

3.3 Causa principale del fallimento

Il layout dello stack prodotto dal compilatore GKI 5.10 di SM8475 su PD2229 (PGO + LTO + BOLT) fa sì che stack_fds di core_sys_select e rt_mutex_waiter di futex_wait_requeue_pi non si sovrappongano architetturalmente. Questo è un fatto oggettivo determinato dal compilatore, non un problema di tecnica di sfruttamento.

Il repository JoinChang afferma esplicitamente: "The pselect stack overlay only works when the freed rt_mutex_waiter lands within the user-controllable region of the stack_fds buffer" — PD2229 non soddisfa questa condizione.

四、Analisi comparativa dei repository di riferimento pubblici

NebuSec/CyberMeowfia — Framework di sfruttamento originale

• Repository: https://github.com/NebuSec/CyberMeowfia
• Target: x86_64 Linux / Pixel 10 (6.x GKI)
• Riciclo stack: PR_SET_MM_MAP copia auxv nello stack del kernel
• Tasso di successo: 97%, circa 5 secondi per [root shell]
• Applicabilità a PD2229: ❌ PR_SET_MM_MAP intercettato con EPERM su Android

JoinChang/ghostlock-oneplus — Jailbreak BL OnePlus

• Repository: https://github.com/JoinChang/ghostlock-oneplus
• Dispositivi verificati:
  • OnePlus Ace 6T (PLR110, SM8845) — 6.12.38 GKI ✅
  • OnePlus 15 (PLK110, SM8845) — 6.12.23 GKI ✅
• Punti tecnici:
  • Estrazione automatica offset: kallsyms (28) + BTF (57) + derivati (9) + costanti (12) = 103/103
  • Sovrapposizione stack pselect, SP diff = -64
  • PSELECT_SHIFT = -2
  • Catena di sfruttamento: futex UAF → waiter falsificato → pselect controlla lo stack → scrittura limitata rb_erase → selinux_state.enforcing=0 → sovrascrittura cred con init_cred
• Dichiarazione esplicita di non fattibilità: "Not Feasible (stack layout incompatible)" — applicabile solo ai kernel in cui pselect stack_fds si sovrappone al waiter
• Applicabilità a PD2229: ❌ Generazione kernel non corrispondente (6.12 vs 5.10) e layout stack non sovrapposto

p2p3p/GhostLock-for-OnePlus — Sfruttamento completo OnePlus 6.12

• Repository: https://github.com/p2p3p/GhostLock-for-OnePlus
• Verificato: OnePlus Ace 6T (SM8845, 6.12.38) ✅
• Applicabilità a PD2229: ❌ Come JoinChang, generazione kernel non corrispondente

YuKongA/ghostlock-oplus — OPPO Find N5/X8

• Repository: https://github.com/YuKongA/ghostlock-oplus
• Kernel: 6.6.118 GKI
• Applicabilità a PD2229: ❌ Generazione kernel non corrispondente

Adattamento OPPO Find X6 Pro (PGEM10) — 5.15.149

• Dispositivo: SM8550, 5.15.149-android13, Android 15
• Progresso: ✅ Bypass KASLR (perf_event_open + campionamento callchain); le fasi successive non hanno pubblicato uno sfruttamento completo
• Significato: dimostra che il bypass KASLR è fattibile su GKI 5.15, ma la fase di riciclo stack non è stata verificata pubblicamente

pubglite55/oppo-ghostlock — OPPO Find N2

• Repository: https://github.com/pubglite55/oppo-ghostlock
• Dispositivo: OPPO Find N2 (CPH2413, SM8475)
• Kernel: 5.10.236-android12-9-o-g74d132f4467a
• Android: 16 (BP2A.250605.015)
• Implementato:
  • ✅ Firefox CVE-2026-10702 AAW (Stage 1)
  • ✅ Bypass KASLR (calcolo diretto di kaslr_base)
  • ✅ Trigger GhostLock FUTEX (FUTEX_CMP_REQUEUE_PI ret=0)
  • ✅ Leak mm_struct KernelSnitch
  • ✅ Heap spray sk_buff (invio 4/4 riuscito)
  • ✅ Verifica 70+ offset con IDA Pro
• Blocco principale:

  "pselect non può manipolare la struttura waiter — con NFDS >336 fd_set è sull'heap; configfs/ashmem non supportati (SET_NAME di ashmem troncato); tutti gli altri percorsi di scrittura kernel bloccati (/proc/self/mem, /dev/mem, binder)"

• Relazione con PD2229: Stessa piattaforma e stessa generazione (SM8475, 5.10.236 vs 5.10.233), differenza di sole 3 versioni minori, affronta esattamente le stesse limitazioni architetturali

harry1080/oppo-ghostlock — OPPO Find N2

• Repository: https://github.com/harry1080/oppo-ghostlock
• Dispositivo: OPPO Find N2 (CPH2413, SM8475)
• Kernel: 5.10.236-android12-9-o-g74d132f4467a
• Android: 16 (BP2A.250605.015)
• Dichiarazione pubblica della community:

  "pixel10 能利用的版本的 pselect stack_fds 正好和 rt_waiter 在内核栈上重合，这个部分实际上是最麻烦的地方，OPPO findN2 的内核这两个调用的栈部分完全不重合，或者重合也不可控，得找另外的控制栈的方法，要换其他可控内核栈的系统调用来构造栈，简单适配偏移是不可能成功的，oppo 的 rt_waiter 完全与 pselect stack_fds 不重合"

• Relazione con PD2229: Anche PD2229 è SM8475 5.10 GKI, la conclusione è pienamente applicabile

4.3 Tabella riepilogativa comparativa dei repository di riferimento

五、Simboli chiave del kernel e offset (misurati su vmlinux PD2229)

Base statica 0xffffffc008000000, aggiungere lo slide KASLR a runtime.

Struttura rt_mutex_waiter (personalizzazione vivo 5.10.233)

struct rt_mutex_waiter {
    uint64_t private;           // +0x00  (campo privato vivo)
    struct rb_node {
        uint64_t rb_parent_color; // +0x08
        uint64_t rb_right;        // +0x10  (ordine invertito da vivo)
        uint64_t rb_left;         // +0x18
    } tree;
    struct task_struct *task;   // +0x20
    struct rt_mutex *lock;      // +0x28
};
// Dimensione totale 0x30 (48 byte)

六、Implementato vs da implementare

✅ Infrastruttura implementata

1. Bypass KASLR — perf_event_open + campionamento callchain (stesso metodo di OPPO Find X6 Pro 5.15.149)
2. Trigger UAF — Deadlock PI a tre thread, FUTEX_CMP_REQUEUE_PI restituisce -EDEADLK
3. Tabella simboli completa — 103+ simboli verificati con IDA (secondo la metodologia di estrazione 103/103 di JoinChang)
4. Layout della struttura rt_mutex_waiter — Offset personalizzati vivo confermati
5. Analisi precisa del layout degli stack frame — Calcolo completato delle profondità dei percorsi futex e pselect/io_uring
6. Esclusione esaustiva di 17 candidati per il riciclo stack — Matrice completa di "non fattibilità" stabilita

❌ Non implementato (blocco principale)

1. Primitiva di riciclo stack — Layout stack del compilatore GKI 5.10 SM8475 architetturalmente inutilizzabile
2. Primitiva di scrittura limitata — rb_erase non attivabile a causa del fallimento del riciclo stack
3. Tutte le fasi successive — Blocco a cascata

七、Conclusione finale

⚠️ GhostLock (CVE-2026-43499) non è sfruttabile su PD2229 (vivo X Fold+, SM8475, 5.10.233 GKI, Android 15 OriginOS 5).

La causa principale è il layout dello stack prodotto dal compilatore GKI 5.10 di SM8475 (PGO+LTO+BOLT), che rende i frame dello stack di tutte le syscall note architetturalmente non sovrapposti a rt_mutex_waiter. Questo è un fatto oggettivo determinato dal compilatore, non un problema di tecnica di sfruttamento.

Tutti i casi di sfruttamento riuscito riguardano GKI 6.6/6.12, perché l'output del compilatore di questi kernel più recenti fa sì che pselect fd_set e waiter si sovrappongano perfettamente (SP diff=-64). Il GKI 5.10 non possiede questa condizione.

Infrastruttura stabilita

• ✅ Primitiva di bypass KASLR (canale laterale perf_event_open)
• ✅ 103+ simboli kernel e offset
• ✅ Layout della struttura rt_mutex_waiter
• ✅ Capacità di trigger UAF
• ✅ Matrice di esclusione di 17 candidati per il riciclo stack

九、Indice dei repository di riferimento