CVE-2026-43499 · Honor WIN RT (AAK-AN00) Temporäre-Root-Forschungsnotizen

(Alles von deepseek geschrieben, ich verstehe überhaupt nichts davon) (Noch ein paar Tage herumprobiert, Fortschritt gleich null, aufgegeben) (Aktuell kann root erlangt werden, aber es ist sehr instabil, nach dem Root bricht das Netzwerk ab, beim Ziehen des Kabels startet das Gerät neu) (Alle Schlussfolgerungen in diesem Repository gelten nur für das Honor WIN RT, die Schwachstelle CVE-2026-43499, den Kernel 6.6.118-android15-8-gf17133276a57-abogki518694926-4k. Verbreite diese Schlussfolgerungen nicht auf temporäres Root – temporäres Root kann dauerhaft und relativ stabil laufen)

Der Bootloader des Geräts ist permanent gesperrt (ro.oem_unlock.supported ist leer), kein fastboot, kein persistentes su, kein Magisk. Der einzige noch gangbare Weg ist eine Kernel-Schwachstelle. Dieses Repository dokumentiert den vollständigen Prozess von „Kann man es überhaupt ausnutzen?" bis „Wie stabil ist es tatsächlich nach der Ausnutzung?".

Art: temporäres Root, nach einem Neustart ungültig.

---

Haftungsausschluss

Dieses Repository dokumentiert einen Sicherheitsforschungsprozess auf einem eigenen Gerät mit dem Ziel, die Ursachen und Stabilitätsgrenzen einer Kernel-PI-Race-Condition zu verstehen.

• Es enthält keinerlei Exploit-Binärdateien oder direkt ausführbare Nutzlasten – Nutzlasten und Framework stammen aus öffentlichen Upstream-Projekten; dieses Repository zitiert sie nur, verbreitet sie nicht weiter.
• Es werden keine Anleitungen für Umgehungsmethoden bestimmter Hersteller bereitgestellt, und die Nutzung auf nicht autorisierten Geräten wird nicht befürwortet.
• Die im Repository enthaltenen Offsets und Symboladressen gelten nur für den einen hier aufgeführten Kernel-Build; bei einem anderen Kernel werden sie alle ungültig.
• Die betreffenden Fehler sind upstream bereits behoben (siehe unten). Der langfristige Wert dieses Dokuments liegt in „dieser Aufzeichnung selbst" – eine echte, unter nicht idealen Bedingungen durchgeführte Praxisanalyse einer Race-Condition-Schwachstelle, einschließlich aller unangenehmen Nebenwirkungen.

---

0. Fazit in einem Satz

Der einzige erfolgreich beschrittene Pfad ist:

CVE-2026-43499 (futex PI Race write-what-where) + rt_sigreturn Carrier
  → LD_PRELOAD-Injektion in einen Shell-Domain-Prozess
  → Zweistufig: zuerst SELinux Permissive setzen, dann task->real_cred / cred auf init_cred ändern
  → uid=0(root) context=u:r:kernel:s0, und einen su-Daemon einpflanzen

Doch was wirklich aufgeschrieben werden sollte, ist nicht „wie man root erlangt" – sondern was danach passiert.

Was man erhält, ist kein stabiles Root, sondern ein „jederzeit zur Explosion bringbarer Zustand".

Die Schreibprimitive des Exploits hängt einen gefälschten rt_mutex_waiter in die echte futex-PI-Kette, und der Träger dieses Waiters ist ein Kernel-Stack / Spray-Page, der von nachfolgenden Systemaufrufen wiederverwendet wird. Daher kann vom Moment der Root-Landung an jede systemweite Scheduling- oder Prioritätsänderung darauf treten und direkt einen Kernel-Panic-Neustart auslösen. Das ist kein Bug, sondern der inhärente Preis dieser Ausnutzungstechnik – siehe docs/03.

---

1. Geltungsgrenzen (bei Abweichung ist das gesamte Vorgehen ungültig)

Punkt	Wert	Beschreibung
Modell	Honor WIN RT, Modell AAK-AN00	Vermarktungsname „Honor WIN RT"
SoC	Snapdragon 8 Elite SM8750-AB	Firmware nicht kompatibel mit Honor WIN (AAP-AN00, SM8850-AC)
System	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Harte Bedingung, zeichengenaue Übereinstimmung
Kernel-Konfiguration	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Voraussetzung für die Carrier-Geometrie
Firmware-Paket	.170	.160 / .175 nicht getestet
Bootloader	Permanent gesperrt	Kein fastboot / kein persistentes su

Warum die Kernel-Version zwingend festgelegt sein muss: Der Fehler wurde in 6.6.140 behoben; das Gerät hat 6.6.118 < 6.6.140, ist also noch betroffen; zugleich sind alle Kernel-Symboladressen und die „Carrier-Geometrie" des Exploits an genau diesen einen Build gebunden. Nach einem Kernel-Wechsel wird die Offset-Tabelle sofort ungültig, und ein Zurückrollen ist in der Regel nicht möglich.

---

2. Überblick über den Privilegieneskalationspfad

┌─ Material ────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (aus Geräte-Firmware extrahiert) │
│        ↓ Symbolauflösung                                │
│ target.h (Kernel-Symboladressen, byteweise mit kallsyms abgeglichen) │
│        ↓ Build                                          │
│ preload.so ──► geräteseitig /data/local/tmp/*.so        │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD-Injektion
     ┌──────────── Zweistufig (zwingend zwei unabhängige Prozesse) ────────────┐
     │ Phase A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Phase B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (durch den „Vorab-Schreiber"-Prozess) │
     │         → setresuid(0,0,0) Normalisierung                   │
     │         → eingebettetes su + Daemon einpflanzen             │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Drei Dinge, die zwingend richtig gemacht werden müssen (sonst hängt es fest oder es kommt direkt zum Panic):

1. Eiserne Reihenfolge: zuerst real_cred, dann cred. Umgekehrte Reihenfolge führt sofort zu vollen Rechten und außer Kontrolle geratenen Threads.
2. Zwischen den beiden Schnitten existiert zwangsläufig ein Übergangszustand mit cred ≠ real_cred. In diesem Moment führt jedes sched_setaffinity zu EPERM → die gesamte Runde hängt fest. Die richtige Lösung ist, noch vor dem ersten Schnitt einen „Vorab-Schreiber"-Prozess zu forken (saubere Credentials); der Elternprozess führt den ersten Schnitt aus, der Schreiber den zweiten, und keiner befindet sich im Übergangszustand, wenn er einen Syscall absetzt.
3. Das Adressmodell ist unabhängig von KASLR. Die gesamte Ausnutzung nutzt nur den linearen Mapping-Alias alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), über Neustarts hinweg stabil; der eigentliche Wert der sogenannten „Slide-Phase" ist die Selbstprüfung der Schreibprimitive, nicht die Umgehung von KASLR.

Upstream-Framework: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Beachte: Dies ist nicht GhostLock – GhostLock nutzt den pselect-Weg, der nicht zur Waiter-Landegeometrie dieses Builds passt, siehe docs/06.

---

3. Verzeichnis