smt878u-ionstack-poc

[!CAUTION] QUESTO PROGETTO È INCOMPLETO — NON FUNZIONA ANCORA. Al 2026-10-06 non esiste alcun root funzionante su nessun dispositivo. Non aspettarti che la guida rapida qui sotto abbia successo. Leggi Stato attuale prima di compilare o eseguire qualsiasi cosa.

[!WARNING] STATO: LAVORI IN CORSO — ring 1 non raggiunto

• Non ottenuto: root persistente o anche solo one-shot su SM-T878U.
• Ultimo fallimento verificato: il payload di stack-reclaim non raggiunge mai il write path del kernel. Su ~470 esecuzioni strumentate il lock forgiato non viene mai osservato come acquisito in rtmutex.c:585, quindi lo store *(ASHMEM_MISC_FOPS) = fake_fops non viene mai eseguito.
• Blocco precedente, ora risolto: la crash forensics non era disponibile per uid 2000 shell (/proc/kmsg, /proc/last_kmsg, /sys/fs/pstore, dmesg → tutti EACCES). Ora un log mirror durevole write()+fsync() (IONSTACK_LOG_MIRROR) sopravvive a CONFIG_PANIC_ON_OOPS=y, quindi un'esecuzione andata in panic lascia comunque una traccia completa.
• Vedi docs/RTMUTEX_WEAPONIZATION.md §15.16–§15.18 per la catena completa delle prove.

Proof of concept di re-root in C puro, assistito dall'host, per Samsung Galaxy Tab S7 (SM-T878U / gts7l) contro CVE-2026-43499 (IonStack / GhostLock).

La catena runtime utilizza esclusivamente componenti nativi C/ELF. Non richiede Python, Java, DEX, app_process o una JVM sul target Android. ADB viene usato per il deployment e la verifica.

---

Stato attuale (INCOMPLETO)

Non è stato ottenuto alcun root. Questa sezione è il resoconto autorevole e aggiornato di dove si trova la catena (ultima revisione 2026-10-06). Tutto quanto segue è misurato su hardware reale (SM-T878U, T878USQS8DXE1, kernel 4.19.113-27114284), non è teoria.

Cosa è dimostrato funzionare

Fase	Stato	Evidenza
Identità del target + leak KASLR	funzionante	[reroot] LEAK_OK kaslr_base=… task=… (side-channel perf)
Trigger CVE: FUTEX_CMP_REQUEUE_PI → -EDEADLK	funzionante	[*] requeue ret=-1 errno=35 — EDEADLK == 35 su Linux
Il rollback difettoso lascia un pi_blocked_on pendente	corrisponde al fix upstream	upstream 3bfdc63936dd cambia current->pi_blocked_on → waiter->task->pi_blocked_on
Layout di struct rt_mutex_waiter (4.19)	verificato dal sorgente	tree_entry@0x00 pi_tree_entry@0x18 task@0x30 lock@0x38 prio@0x40 deadline@0x48
Geometria dello stack paint == rt_waiter + 0x28	verificato 4× incl. objdump	rt_waiter = do_futex_sp+0xC0; address = ___sys_sendmsg_sp+0xB8
Crash forensics durevole	funzionante	la traccia IONSTACK_LOG_MIRROR write()+fsync() sopravvive a un riavvio da panic
Tag d'identità per frag-page per messaggio	funzionante	reclaim-scan tag=1 sent=8201 range=1..8201 ok=8192 bad=0 dup=0 undecoded=0 absent=9
Scansione della coda: il kernel ha scritto 0 byte nelle 8192 frag page in coda	verificato	256 MB confrontati byte per byte con il payload, hits=0
rt_mutex_adjust_prio_chain raggiunge il write path	verificato dal disassemblato	top_waiter == NULL ⇒ requeue resta true ⇒ 664/682/685/716-725 strutturalmente raggiungibili

Cosa NON funziona

1. Il percorso di scrittura non viene mai eseguito. Su circa 470 esecuzioni strumentate, tutte le 174 osservazioni page-dump e le 45 osservazioni ring1-page riportano first_diff=8000 (pristine), owner_cpu=00000000, case1_gate=0 e lock_root/lock_leftmost esattamente uguali al valore del payload. Non è mai stato osservato che la walk assuma fake_lock->wait_lock a rtmutex.c:585, quindi 664/682/685/716-725 — l'unico ramo che può scrivere in *(ASHMEM_MISC_FOPS) — non è mai stato eseguito. Si noti che _raw_spin_trylock()/_raw_spin_unlock() passano attraverso helper out-of-line e questo albero vendor non ha alcun override arm64 di queued_spin_unlock, quindi wait_lock.val == 1 è il testimone affidabile di 585 e owner_cpu != 0 è solo secondario.
2. Il veicolo pubblicato non è disponibile qui. L'unico exploit pubblico riuscito di questa CVE (NebuSec, IonStack part II) recupera il frame con prctl(PR_SET_MM, PR_SET_MM_MAP, …). Questo kernel include # CONFIG_CHECKPOINT_RESTORE is not set, quindi quella syscall è esclusa dalla compilazione. Inoltre non usa mai sendmsg — il nostro veicolo — che è molto probabilmente la causa principale di (1).
3. ring1-read non è mai stato eseguito. L'unica rilettura userspace del ring 1 (configfs_read_once(fd, data_addr(ASHMEM_MISC_FOPS), …)) si trova dietro il gate di scansione della coda e dietro il default MARKER dell'harness, che si ferma 8 s prima a ring1-page. Ogni esecuzione che ha raggiunto il gate è terminata tra page-dump tag=pre-arm e page-dump tag=post-arm.

Prossimi passi immediati (in ordine di priorità)

1. Rieseguire l'unica configurazione in cui 664/682/685 possono completarsi all'interno della nostra stessa pagina — IONSTACK_FOPS_WAIT_LOCK_WORD=0 con IONSTACK_PAINT_WAITER_TASK_MODE=fake-task — e leggere page-dump tag=post-arm / ring1-lock585 per wait_lock=00000001.
2. Far eseguire ring1-read: eseguire con IONSTACK_RECLAIM_SCAN_QUEUE non impostato e MARKER='ring1-read|…' in modo che l'harness non si fermi a ring1-page.
3. Identificare la pagina trattenuta: eseguire con IONSTACK_RECLAIM_TAG=1 e confrontare pipe_tag con msg_tag in page-dump. Tutte le pagine frag sono copie byte-identiche del payload, quindi first_diff da solo non può distinguerle.
4. Riesaminare la questione IONSTACK_FOPS_WAIT_LOCK_WORD su una base posta correttamente — wlw=0 vs wlw=1 con IONSTACK_RECLAIM_TAG mantenuto costante. La correlazione precedente era confusa dal fatto che le due variabili si muovevano insieme.
5. Portare la superficie di paint pselect6 res_in/res_out dal port K40 4.19.
6. Solo allora convertire la primitiva di scrittura in escalation di privilegi.

Bug aperto non correlato

fops.c:3157 reason=selinux_write ret=-1 errno=22 EINVAL — ancora irrisolto.

---

Documentazione