CVE-2021-28664-PoC

Mali kbase GPU-Treiber UAF (CVE-2021-28664) → Kernel beliebiger physischer Speicher Lese-/Schreibprimitive PoC-Gerüst. Ausgerichtet auf generische ARM64-Android-Plattformen, unabhängig von konkretem Hersteller oder Modell.

Der Forschungsbereich endet genau bei "Kernel beliebiger physischer Speicher Lese-/Schreibprimitive": Wie man einen Use-after-free in einem GPU-Treiber in eine stabile, kontrollierbare und sicher fehlschlagende Kernel-Speicher-Lese-/Schreibfähigkeit verwandelt.

Dieses Repository stellt keinen Angriff bereit. Es enthält keinen fertigen Exploit, keinen direkt ausführbaren Code, keine Offset-/Seriennummern-/Firmware-Daten für irgendein Gerät; die Verwendung jeglicher Inhalte für Angriffshandlungen ist verboten (siehe unten).

Haftungsausschluss / Disclaimer (Pflichtlektüre)

1. Dieses Repository stellt keinen Angriff bereit. Dieses Repository ist eine technische Aufarbeitung der Schwachstellenprinzipien und Speicherzerstörungsprimitive; es enthält ausschließlich Methodendokumentation und Lehrvorlagen, bei denen alle gerätespezifischen Werte leer gelassen wurden. Es kann nicht direkt zum Angriff auf irgendein Gerät verwendet werden.
2. Angriffe verboten. Die Verwendung der Inhalte dieses Repositories für nicht autorisierte Geräte, Geräte Dritter oder jegliche illegale Zwecke ist strengstens untersagt; alle daraus resultierenden Konsequenzen trägt der Nutzer selbst, der Autor ist nicht verantwortlich.
3. Forschungsexperimente wurden ausschließlich auf Geräten durchgeführt, die dem Autor selbst gehören, mit dem Ziel der Schwachstellenreproduktion und Sicherheitsforschung.
4. CVE-2021-28664 wurde 2021 upstream (Arm/Mali) behoben; betroffen sind langfristig nicht aktualisierte alte Treiber/alte Firmware. Die Bedeutung dieser Forschung liegt im Verständnis der Ausnutzungsprinzipien historischer Schwachstellen und der Detektionsansätze aus Verteidigungsperspektive.
5. Die Inhalte dieses Repositories werden "AS IS" bereitgestellt, ohne jegliche ausdrückliche oder stillschweigende Gewährleistung.
6. Falls Sie als Hersteller/Sicherheitsteam weitere Details benötigen, kontaktieren Sie den Autor bitte über GitHub.

Anwendungsbereich

Technisch anwendbar (Voraussetzungen dafür, dass jede Phase der Ausnutzungskette gültig ist)

Technisch nicht anwendbar

• Mali-Treiber, bei dem CVE-2021-28664 bereits behoben wurde (nach dem Fix der r-Version);
• Nicht-Mali-GPU-Plattformen (diese Kette hängt stark vom alias/MMU-dump-Verhalten von kbase ab);
• Neuere Kernel mit stark abweichender pipe_buffer-Struktur/copy_page_to_iter-Validierung (ab 5.x muss anhand des entsprechenden Quellcodes neu geprüft werden; die Kettenstruktur kann als Referenz dienen, aber Details sind nicht allgemeingültig);
• Umgebungen ohne /dev/mali-Zugriffsberechtigung (seLinux-/Herstellerrichtlinien-Beschränkungen).

Abgrenzungserklärung

• Dieses Repository deckt nur Lese-/Schreibprimitive ab; die Lokalisierung konkreter Kernel-Ziele nach Erhalt der Primitive, weitere Ausnutzung oder Privilegieneskalation liegen nicht im Umfang dieses Repositories.
• Alle gerätespezifischen Konstanten sind in den Vorlagen mit TODO(DEVICE) leer gelassen; die Anpassung ist die eigene Reverse-Engineering-Arbeit des Nutzers, das Repository übernimmt dies nicht.

Schwachstellenhintergrund

CVE-2021-28664: Der MEM_ALIAS-Pfad des Mali kbase Treibers entbehrt einer Prüfung der GPU_WR-Berechtigung; ein Angreifer kann bereits freigegebene GPU-Speicherseiten in seinen eigenen GPU-Adressraum aliasen, wodurch eine "GPU-seitige dauerhafte Sichtbarkeit/Beschreibbarkeit freigegebener physischer Seiten" entsteht – ein Use-after-free über die GPU/Kernel-Grenze hinweg.

Der Ausnutzungswert liegt nicht im GPU-Speicher selbst, sondern darin:

1. Die freigegebenen physischen Seiten werden vom Kernel-slab/buddy an Kernel-Objekte neu zugewiesen (in dieser Forschung: pipe_buffer);
2. Die GPU-alias-Ansicht kann diese Seiten weiterhin sehen → Lesen/Schreiben von Feldern von Objekten, die der Kernel gerade verwendet;
3. Mit Hilfe von GPU WRITE_VALUE-Jobs gezielte Änderungen an alias-sichtbaren Seiten durchführen.

Wie weit diese Forschung geht

victim GPU-Puffer + MMU-Seitentabellen-Dump → physische Adresskarte erstellen
  → Trigger-Pufferfreigabe erzeugt Druck → Pipe-Spray (F_SETPIPE_SZ verkleinern)
  → pipe_buffer-Array landet im freigegebenen Bereich (Cross-Cache-UAF-Wiederverwendung)
  → alias-Ansicht scannt ops-Zeiger → anon_pipe_buf_ops leaken → KASLR slide
  → GPU modifiziert page / offset / len des pipe_buffer
  → mit Hilfe des legitimen pipe read/write-Pfads
  ⇒ beliebiges physisches Seitenlesen (gefälschter page-Zeiger)
  ⇒ beliebiges physisches Seitenschreiben (pipe merge-Schreibpfad)
  ⇒ mit bekannter Inhaltsseite als Selbstbeweis-Oracle, um sicherzustellen, dass Lesen/Schreiben nicht in Lücken/unmapped-Bereiche fällt

Bis hierhin.

Zentrale technische Punkte (jeder Punkt hat einen eigenen Abschnitt in docs/)

• Mehrstufige Sicherheitstore: Vor jedem physischen Lesen müssen mehrere Tore wie overlap / Selbstkonsistenz / Kontiguität / Inhalts-Selbstbeweis passiert werden; bei jedem Fehlschlag sofort die Szene wiederherstellen und beenden – die wichtigste Engineering-Disziplin der gesamten Forschung.
• Fallstricke des physischen Adressmodells: Verunreinigung der GPU-PTE-Software-Flags, 32-Bit-Abschneidung physischer Adressen, KASLR randomisiert auch die physische Basisadresse des Kernel-Images, Unterschiede in der herstellerspezifischen page_to_virt-Implementierung, no-map-Reservierungsbereiche existieren im linearen Mapping überhaupt nicht (Lesen führt zu panic).
• m-Ambiguitätsbehandlung: Hohe Bits der physischen Adresse werden niemals geraten; stattdessen wird ein "bekannte-Inhaltsseite-Oracle" für den Inhalts-Selbstbeweis verwendet.
• Primitiv-Lebensdauer und sicheres Fehlschlagen: Lese-Sonden haben ein Versuchsbudget; nach Überschreitung muss die aktuelle Runde aufgegeben werden; jeder Exit-Pfad jedes Experiments muss die manipulierten Objektfelder wiederherstellen.

Repository-Struktur

docs/
  01-exploit-chain.md            Von UAF zu Lese-/Schreibprimitiven: Prinzipien und Implementierungspunkte jeder Phase
  02-physical-address-model.md   Physisches Adressmodell, Sicherheitstore, m-Ambiguität, bekannte Fallstricke
exploit/
  cve-2021-28664-poc.c           PoC-Vorlage: vollständiges Prozessgerüst der Lese-/Schreibprimitive (ohne Gerätewerte)
scripts/
  README.md                      Designbeschreibung der experimentellen Automatisierungswerkzeuge (Schleife/Validierung/Wiederherstellung)

Quellcode-Beschreibung

exploit/cve-2021-28664-poc.c ist die PoC-Gerüstvorlage der Lese-/Schreibprimitive:

• Behält die vollständige Prozessstruktur bei (Ressourcenvorbereitung → Spray → Scan → Kalibrierung → Lese-/Schreibprimitive → Wiederherstellung und Exit);
• Alle gerätespezifischen Konstanten sind mit TODO(DEVICE) gekennzeichnet, keine direkt verwendbaren Werte;
• Vor jeder gefährlichen Operation gibt es explizite Validierungstore und Wiederherstellungspfade, die das Design des "sicheren Fehlschlagens" demonstrieren.

Es dient dem Verständnis, wie die gesamte Kette organisiert ist, und kann nicht direkt zu einem für irgendein Gerät wirksamen Werkzeug kompiliert werden.

Referenzen

• ARM Mali kbase Treiber (öffentlicher Kernel-Quellcodebaum)
• CVE-2021-28664 Upstream-Fixaufzeichnung und öffentliche Analysen
• Linux fs/pipe.c / include/linux/pipe_fs_i.h (öffentlicher Quellcode)
• arm64 Speichermodell: Documentation/arch/arm64/memory.rst (öffentliche Dokumentation)

License

• Code (exploit/): GPL-3.0, siehe LICENSE
• Dokumentation (README, docs/, scripts/): CC BY-NC-SA 4.0, siehe LICENSE-DOCS (kommerzielle Nutzung verboten; abgeleitete Inhalte müssen unter gleichen Bedingungen geteilt werden und dieser Hinweis muss erhalten bleiben)