CVE-2026-64560 — Toolchain + Multi-Target-Portierung

CVE-2026-64560 ist ein Use-after-free in den Linux-Kernel-posix-cpu-timers (lokale unprivilegierte Race, CVSS 3.1 = 7.8; in 6.6.118 nicht behoben, erst in 6.6.147). Dieses Repository hat zwei Aufgaben: die Upstream-Toolchain, die sich nur über eine Reihe von Python-Skripten steuern lässt, in eine einzelne statische Go-Binary zu verwandeln, und das Upstream fehlende Ziel realme RMX5010 (A16 / SM8750) zu ergänzen.

[!WARNING] Dies ist experimenteller Kernel-Exploit-Code. Er kann das Gerät neu starten, den Kernel-Zustand beschädigen oder Datenverlust verursachen. Verwende ihn nur auf Geräten, die dir gehören oder für die du eine ausdrückliche Genehmigung hast. Erstelle zuerst ein Backup.

Ziele

Fertige Artefakte direkt verwenden

Kein Go, kein Python nötig:

• Release: Wird beim Taggen von v* automatisch veröffentlicht, enthält Tools für alle Plattformen + Payloads für alle Ziele + SHA256SUMS.txt
• Actions-Artefakte: Werden bei jedem Push auf main erzeugt
  • cve64560-<os>-<arch>: linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads: aarch64-Statikpayloads für jedes Profil (rmx5010-a16-…, op13-…, jeweils in ein eigenes Verzeichnis geschrieben, kein gegenseitiges Überschreiben mehr)

Die android/arm64-Variante kann direkt per adb push nach /data/local/tmp geschoben und auf dem Handy ausgeführt werden.

Selbst kompilieren

go build -o cve64560 ./gotool                 # Tool (reines Go, keine Abhängigkeiten)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # Payload (benötigt cc)

Eine Übersicht der Kommandozeile, --dry-run-Leerlauf und die Ableitung der Profile findest du in docs/GOTOOL.md.

Warum die Toolchain in Go ist

Der ursprüngliche Ablauf benötigte python3 + tools/*.py + eine Reihe von Shell-Skripten: Auf Testmaschinen gibt es kein Python, auf Handys erst recht nicht. Jetzt deckt eine einzige statische Binary den gesamten Ablauf kallsyms → derive → render → patch → build → campaign ab und läuft überall, wohin sie cross-kompiliert wird.

Die Python-Implementierung wurde nicht entfernt: Sie bleibt in tools/ als Referenzimplementierung und CI-Vergleichsbasis erhalten. Die CI führt für jedes Profil sowohl Go als auch Python aus und macht dann diff -r; bei byteweiser Abweichung wird es rot.

Was die CI macht (.github/workflows/build.yml)

Verzeichnisse

gotool/           Go-Toolchain (ein Befehl pro Datei)
profiles/         Ziel-Profile (eine JSON pro Ziel, einzige Quelle der Wahrheit für das Rendering)
src/              Upstream-Vorlagen + gerenderter Gerätequellcode
tools/            Upstream-Python-Referenzimplementierung + musl/bionic-Kompatibilitätsschicht + CI-Skripte
scripts/          Upstream-Kampagnen-/Messskripte (Go-Version siehe gotool/cmd_campaign.go)
targets/          Kernel-Symbole/Offsets-Aufzeichnungen pro Ziel
symbols/          Kernel-Symboltabellen der beiden ausgelieferten Profile (die übrigen Ziele sind abgeleitete Daten)
docs/GOTOOL.md    Dokumentation der Go-Toolchain

Sicherheitsgrenzen

Das Repository enthält keine Firmware-Images, Geräteschlüssel oder geräteindividuelle Identifikatoren. Schritte, die ein Hersteller-Kernel-Image zur Reproduktion erfordern (Symbole extrahieren, Profile ableiten), bringen das Original-Image mit und werden nicht ins Repository aufgenommen.

Die einzige Ausnahme sind die Kernel-Symboltabellen der beiden ausgelieferten Profile (symbols/symbols_*.json, je ca. 9 MB): build schlägt fehl, wenn es die Tabelle nicht findet (es wird keine Payload mit ungeprüften Konstanten ausgeliefert), und die CI hat kein Kernel-Image zur Hand, um die Tabellen neu zu erstellen. Sie enthalten nur Symbolnamen und Adressen, nicht das Image selbst.

Die Payload ist temporäres Root: Sie erlischt beim Neustart, wird nicht auf die Festplatte geschrieben und verändert keine Partitionen.