CVE-2025-21479 — Qualcomm Adreno GPU Privilege Escalation Exploit (SM8475 / iQOO Neo8)

Lokaler Privilege-Escalation-Proof-of-Concept-Code für CVE-2025-21479, der auf die Qualcomm-Adreno-GPU (KGSL) des vivo V2301A (iQOO Neo8 / PD2301, Snapdragon 8+ Gen 1 / SM8475, Adreno A730, Android 14, GKI-Kernel 5.10) abzielt.

Im Prinzip treibt der Exploit über den KGSL-Befehl CP_SMMU_TABLE_UPDATE die SMMU der GPU an, erlangt beliebigen physischen Speicherzugriff (Lesen/Schreiben), deaktiviert daraufhin SELinux, lokalisiert Kernel-Symbole und erlangt eine Root-Shell – ganz ohne Flashen und ohne entsperrten Bootloader.

Nur für Sicherheitsforschung an Geräten, die dir selbst gehören oder für die du autorisiert bist.

Was es tut

1. GPU-Physischer-Speicher-Primitive. Die Zugriffsprüfung (and $12, 0x3) der Adreno-A730-Mikrocode (eureka_panther) ist fehlerhaft und klassifiziert Self-Draw-State (SDS)-Pakete fälschlich als RingBuffer (RB). Indem ein gefälschter CP_SMMU_TABLE_UPDATE im SDS-Block aus dem User-Mode übergeben wird, kann TTBR0 der GPU überschrieben werden, sodass die GPU-Seitentabelle auf beliebige physische Seiten zeigt – die GPU kann danach beliebigen physischen Speicher lesen und beschreiben.
2. Stabilisiertes Lesen/Schreiben. Durch stabilize_rw wird das Mapping zu einer 2-MB-Self-Mapping-Region gehärtet, die schnelle Massen-Lesevorgänge unterstützt (fast_pread_bytes usw.).
3. SELinux deaktivieren. Im physischen Speicher wird das Feld selinux_state.enforcing auf Null gesetzt. Danach wird das Kernel-Image von der festen physischen Basisadresse 0xA8000000 aus gedumpt (Standard-Obergrenze 43 MB) – SM8475 hat kein physisches KASLR – und die kallsyms-Strukturen werden direkt aus dem rohen Dump analysiert (Endianness wird automatisch erkannt), sodass auch virtuelles KASLR keinen Einfluss hat.
4. Root-Payload. Eine AArch64-Shellcode-Sequenz (prepare_kernel_cred(0) → commit_creds(), zusätzlich seccomp deaktivieren) patcht __do_sys_capset. Ein per fork erzeugter Kindprozess ruft capset() auf → wird uid 0 → stellt den überschriebenen Kernel-Code wieder her → der Kindprozess führt im Domänenkontext u:r:shell:s0 den von dir angegebenen Befehl erneut aus (Standard sh). Der Kernel-Code ist am Ende byteweise identisch mit dem Zustand vor der Ausführung.

Testgerät

Vollständige Geräteinformationen siehe device_info.txt.

Repository-Struktur

├── source/
│   ├── cheese.c            # Exploit-Hauptprogramm (inkludiert die beiden folgenden Dateien)
│   ├── kallsyms_lookup.c   # kallsyms-Parser für rohe Kernel-Images
│   └── adrenaline.h        # KGSL-ioctl-/Befehlsdefinitionen (Autor hawkes)
├── exploit                 # Vorkompiliertes arm64-Binary (dynamisch gelinkt, minSdk 21,
│                           #  NDK r30-beta2)
├── device_info.txt         # Zielgeräteinformationen zur Parameterabstimmung
└── README.md

Hinweis: cheese.c verwendet #include für kallsyms_lookup.c und adrenaline.h; beim Kompilieren müssen sich die drei Dateien im selben Verzeichnis befinden.

Kompilierung

Jedes neuere Android-NDK (r25+) ist geeignet, Beispiel:

# Statisch linken (eigenständig, läuft auf jeder API-Stufe; größere Datei)
aarch64-linux-android34-clang -o cheese source/cheese.c -static

# Dynamisch linken (kleine Datei, nutzt die geräteeigene libc; API-Stufe muss zum Gerät passen)
aarch64-linux-android34-clang -o exploit_dyn source/cheese.c
# Für Kompatibilität mit API-21+-Geräten bitte aarch64-linux-android21-clang verwenden

Verwendung

adb push exploit /data/local/tmp/

adb shell
chmod +x /data/local/tmp/exploit
/data/local/tmp/exploit

Ausführliches Tutorial hier (enthält ein Ein-Klick-Tool)

Nach Erfolg erhältst du eine Shell mit uid=0, und SELinux ist in dieser Sitzung deaktiviert. Nach Abschluss der Rechteausweitung führt der Prozess argv[1..] erneut aus (Standard sh). Bei jedem Lauf gibt es einen Countdown ("pte wait 3 second") und einen 43-MB-Kernel-Lesefortschritt ("Read X / 43 MB").

Umgebungsvariablen

ReSukiSU-Root

$(find /data/app -type f -name "libksud.so" | grep resukisu) late-load --kmi android12-5.10

Portierung auf andere Geräte

Gerätebezogene Konstanten befinden sich oben in source/cheese.c:

• KERNEL_PHYS_BASE — physische Kernel-Basisadresse (Standard 0xA8000000, SM8475)
• IDMAP_PG_DIR_OFFSET — idmap_pg_dir-Offset (Standard 0x245a000)
• selinux_state_offset — Offset zum Auffinden von selinux_state (Standard 0x729030, tatsächliche physische Adresse = physische Adresse von idmap_pg_dir + dieser Offset)
• gPhyAddrs[] — nacheinander versuchte Kandidaten-Basisadressen
• DEFAULT_KERNEL_SIZE_MB — Fallback-Wert / Obergrenze für den Kernel-Lesevorgang

Voraussetzungen: Adreno-A730/A7xx-GPUs (betroffene Firmware), ein Kernel, dessen kallsyms aus dem physischen Dump auflösbar ist, und kein physisches KASLR.

Häufige Fragen

• can't get GPU r/w — GPU-Initialisierung fehlgeschlagen; zuerst warten, wenn es weiterhin nicht klappt, CHEESE_ATTEMPT=1..n versuchen oder CHEESE_PHYADDR manuell angeben; für Debugging eines einzelnen Versuchs CHEESE_NO_RETRY=1 hinzufügen.
• kallsyms-Analyse fehlgeschlagen — zuerst mit CHEESE_READ_FULL_KERNEL=1 das vollständige Image lesen (zusammen mit CHEESE_KALLSYMS_MAX_MB das Limit erhöhen), danach CHEESE_FORCE_MANUAL_PATCHFINDER=1 in Betracht ziehen.
• Dieses Tool flasht nichts und macht nichts persistent: Kernel-Code und Seitentabellen werden vor dem Ende wiederhergestellt; nach einem Neustart ist das Gerät exakt im Zustand wie vor der Ausführung.

Danksagungen

• @zhuowei — Forscher von CVE-2025-21479 und Autor des quelloffenen cheese-Exploits, auf dem dieses Tool basiert
• cheese / cheese-cake Open-Source-Linie — SDS/TTBR0-Technik, kallsyms-Analyse auf Basis von Kernel-Dumps
• hawkes — KGSL-Header adrenaline.h von 2020, liefert die ioctl-Schnittstellendefinitionen
• 酷安@renil — Forschung zur Reproduktion dieser Schwachstelle auf dem iQOONeo8

Basiert auf zhuowei/cheese (Original-Repository ohne Lizenz). Vollständige technische Details siehe Schwachstellen-Meldung.

• 酷安@TNTHe — mein Coolapk-Konto

Haftungsausschluss

Dieses Repository dient ausschließlich Bildungs- und Sicherheitsforschungszwecken; bitte verwende es nur auf Geräten, die dir selbst gehören oder für die du autorisiert bist. Der Autor übernimmt keine Verantwortung für Missbrauch. Die Verwendung dieses Tools kann zum Erlöschen der Garantie oder zu Verstößen gegen entsprechende Nutzungsbedingungen führen.