smt878u-ionstack-poc

[!CAUTION] DIESES PROJEKT IST UNVOLLENDET — ES FUNKTIONIERT NOCH NICHT. Es gibt kein funktionierendes Root auf irgendeinem Gerät mit Stand 2026-10-06. Erwarten Sie nicht, dass der untenstehende Schnellstart erfolgreich ist. Lesen Sie Aktueller Status, bevor Sie irgendetwas bauen oder ausführen.

[!WARNING] STATUS: IN ARBEIT — Ring 1 nicht erreicht

• Nicht erreicht: persistentes oder auch nur einmaliges root auf SM-T878U.
• Zuletzt verifizierter Fehlschlag: Die Stack-Reclaim-Nutzlast erreicht nie den Schreibpfad des Kernels. Über ~470 instrumentierte Läufe hinweg wird die gefälschte Sperre nie als bei rtmutex.c:585 genommen beobachtet, sodass der Store *(ASHMEM_MISC_FOPS) = fake_fops nie ausgeführt wird.
• Früherer Blocker, jetzt behoben: Crash-Forensik war zuvor für uid 2000 shell nicht verfügbar (/proc/kmsg, /proc/last_kmsg, /sys/fs/pstore, dmesg → alle EACCES). Ein dauerhafter write()+fsync()-Log-Spiegel (IONSTACK_LOG_MIRROR) überlebt nun CONFIG_PANIC_ON_OOPS=y, sodass ein gepanickter Lauf dennoch eine vollständige Spur hinterlässt.
• Siehe docs/RTMUTEX_WEAPONIZATION.md §15.16–§15.18 für die vollständige Beweiskette.

Reiner C-, hostgestützter Re-Root-Proof-of-Concept für das Samsung Galaxy Tab S7 (SM-T878U / gts7l) gegen CVE-2026-43499 (IonStack / GhostLock).

Die Laufzeitkette verwendet ausschließlich native C/ELF-Komponenten. Sie benötigt kein Python, Java, DEX, app_process oder eine JVM auf dem Android-Ziel. ADB wird für Deployment und Verifikation verwendet.

---

Aktueller Status (UNVOLLENDET)

Es wurde kein Root erlangt. Dieser Abschnitt ist die maßgebliche, aktuelle Darstellung des Stands der Kette (zuletzt überarbeitet am 2026-10-06). Alles untenstehende ist auf echter Hardware gemessen (SM-T878U, T878USQS8DXE1, Kernel 4.19.113-27114284), nicht theoretisch.

Was nachweislich funktioniert

Phase	Status	Nachweis
Zielidentität + KASLR-Leak	funktioniert	[reroot] LEAK_OK kaslr_base=… task=… (Perf-Seitenkanal)
CVE-Trigger: FUTEX_CMP_REQUEUE_PI → -EDEADLK	funktioniert	[*] requeue ret=-1 errno=35 — EDEADLK == 35 unter Linux
Fehlerhafter Rollback hinterlässt baumelndes pi_blocked_on	entspricht Upstream-Fix	Upstream 3bfdc63936dd ändert current->pi_blocked_on → waiter->task->pi_blocked_on
Layout von struct rt_mutex_waiter (4.19)	aus dem Quellcode verifiziert	tree_entry@0x00 pi_tree_entry@0x18 task@0x30 lock@0x38 prio@0x40 deadline@0x48
Stack-Geometrie paint == rt_waiter + 0x28	4× verifiziert, inkl. objdump	rt_waiter = do_futex_sp+0xC0; address = ___sys_sendmsg_sp+0xB8
Dauerhafte Crash-Forensik	funktioniert	IONSTACK_LOG_MIRROR write()+fsync()-Spur überlebt einen Panic-Reboot
Identitäts-Tag pro Nachricht für Frag-Pages	funktioniert	reclaim-scan tag=1 sent=8201 range=1..8201 ok=8192 bad=0 dup=0 undecoded=0 absent=9
Queue-Scan: Kernel schrieb 0 Bytes in 8192 eingereihte Frag-Pages	verifiziert	256 MB Byte-für-Byte gegen die Nutzlast verglichen, hits=0
rt_mutex_adjust_prio_chain erreicht den Schreibpfad	aus der Disassembly verifiziert	top_waiter == NULL ⇒ requeue bleibt true ⇒ 664/682/685/716-725 strukturell erreichbar

Was NICHT funktioniert

1. Der Schreibpfad wird nie ausgeführt. Über ~470 instrumentierte Läufe hinweg melden alle 174 page-dump- und 45 ring1-page-Beobachtungen first_diff=8000 (pristine), owner_cpu=00000000, case1_gate=0 und lock_root/lock_leftmost exakt gleich dem Payload-Wert. Der Walk hat nie fake_lock->wait_lock bei rtmutex.c:585 genommen, sodass 664/682/685/716-725 — der einzige Zweig, der in *(ASHMEM_MISC_FOPS) schreiben kann — nie ausgeführt wurde. Beachten Sie, dass _raw_spin_trylock()/_raw_spin_unlock() über Out-of-Line-Helper laufen und dieser Vendor-Tree kein arm64-queued_spin_unlock-Override hat, sodass wait_lock.val == 1 der zuverlässige 585-Zeuge ist und owner_cpu != 0 nur ein sekundärer.
2. Das veröffentlichte Vehikel ist hier nicht verfügbar. Der einzige öffentlich erfolgreiche Exploit dieser CVE (NebuSec, IonStack part II) reklamiert den Frame mit prctl(PR_SET_MM, PR_SET_MM_MAP, …). Dieser Kernel wird mit # CONFIG_CHECKPOINT_RESTORE is not set ausgeliefert, sodass dieser Syscall herauskompiliert ist. Er verwendet außerdem nie sendmsg — unser Vehikel —, was sehr wahrscheinlich die Ursache von (1) ist.
3. ring1-read wurde nie ausgeführt. Der einzige Userspace-Read-back von Ring 1 (configfs_read_once(fd, data_addr(ASHMEM_MISC_FOPS), …)) liegt hinter dem Queue-Scan-Gate und hinter dem Harness-MARKER-Default, der 8 s früher bei ring1-page stoppt. Jeder Lauf, der das Gate erreichte, starb zwischen page-dump tag=pre-arm und page-dump tag=post-arm.

Unmittelbare nächste Schritte (in Prioritätsreihenfolge)

1. Die eine Konfiguration erneut ausführen, in der 664/682/685 innerhalb unserer eigenen Seite abschließen können — IONSTACK_FOPS_WAIT_LOCK_WORD=0 mit IONSTACK_PAINT_WAITER_TASK_MODE=fake-task — und page-dump tag=post-arm / ring1-lock585 auf wait_lock=00000001 prüfen.
2. ring1-read zur Ausführung bringen: mit nicht gesetztem IONSTACK_RECLAIM_SCAN_QUEUE und MARKER='ring1-read|…' laufen lassen, damit die Harness nicht bei ring1-page stoppt.
3. Die gehaltene Seite identifizieren: mit IONSTACK_RECLAIM_TAG=1 laufen lassen und pipe_tag gegen msg_tag im page-dump vergleichen. Alle Frag-Seiten sind byte-identische Kopien des Payloads, sodass first_diff allein sie nicht unterscheiden kann.
4. Die Frage zu IONSTACK_FOPS_WAIT_LOCK_WORD auf korrekt gestellter Basis erneut testen — wlw=0 vs. wlw=1 bei konstant gehaltenem IONSTACK_RECLAIM_TAG. Die frühere Korrelation war durch die gemeinsame Bewegung beider Variablen verfälscht.
5. Die res_in/res_out-pselect6-Paint-Oberfläche aus dem K40-4.19-Port übernehmen.
6. Erst dann das Schreib-Primitiv in Privilegieneskalation umwandeln.

Unabhängiger offener Bug

fops.c:3157 reason=selinux_write ret=-1 errno=22 EINVAL — weiterhin ungelöst.

---

Dokumentation

Dokument	Inhalt
docs/RTMUTEX_WEAPONIZATION.md	Vollständige Beweiskette für die rtmutex-Kette (größtes Dokument)
docs/ROOT_CHAIN_THEORY.md	End-to-End-Design der Root-Kette von Ring 0→4
docs/PAINT_ORACLE_ANALYSIS.md	Warum das Stack-Paint-Orakel so liest, wie es liest
docs/PSELECT_GEOMETRY_FINDINGS.md	pselect6 als alternatives Paint-Vehikel
docs/RING1_RECLAIM_IDENTITY_2026-10-06.md	Identitäts-Tag pro Nachricht für Frag-Seiten; Queue-Scan-Verifikation
docs/RING1_585_NEVER_SUCCEEDED_2026-10-06.md	Nachweis, dass rtmutex.c:585 nie erfolgreich war
docs/RING1_ORACLE_FIX_2026-10-05.md	Orakel-Korrektur
docs/RING1_ORACLE_WRONG_FRAGMENT_2026-10-06.md	Warum das gehaltene Fragment falsch identifiziert wurde

---