CVE-2026-64560 — Toolchain + porting multi-target

CVE-2026-64560 è una use-after-free in posix-cpu-timers del kernel Linux (race locale non privilegiata, CVSS 3.1 = 7.8; non corretta in 6.6.118, corretta solo in 6.6.147). Questo repository fa due cose: trasforma la toolchain upstream, che può essere guidata solo da una serie di script Python, in un singolo binario Go statico, e aggiunge il target realme RMX5010 (A16 / SM8750) che upstream non ha.

[!WARNING] Questo è codice exploit sperimentale per il kernel. Può riavviare il dispositivo, corrompere lo stato del kernel o causare perdita di dati. Usalo solo su dispositivi che possiedi o per cui hai un'autorizzazione esplicita. Fai prima un backup.

Target

Ottenere direttamente gli artefatti pronti

Senza installare Go, senza installare Python:

• Release: pubblicate automaticamente al push di un tag v*, contengono i tool per ogni piattaforma + i payload per ogni target + SHA256SUMS.txt
• Actions artifacts: generati a ogni push su main
  • cve64560-<os>-<arch>: linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads: i payload statici aarch64 per ogni profile (rmx5010-a16-…, op13-…, ciascuno nella propria directory, senza più sovrascriversi a vicenda)

Quello android/arm64 può essere copiato direttamente con adb push in /data/local/tmp ed eseguito sul telefono.

Compilare da soli

go build -o cve64560 ./gotool                 # tool (Go puro, nessuna dipendenza)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # payload (richiede cc)

Per la panoramica della riga di comando, l'esecuzione a vuoto con --dry-run e come vengono derivati i profile, vedi docs/GOTOOL.md.

Perché la toolchain è in Go

Il flusso originale richiedeva python3 + tools/*.py + una serie di shell: sulle macchine di test non c'è python, figurarsi sul telefono. Ora un singolo binario statico copre l'intero flusso kallsyms → derive → render → patch → build → campaign, e può girare ovunque venga cross-compilato.

L'implementazione Python non è stata rimossa: resta in tools/ come implementazione di riferimento e baseline di confronto per la CI, la CI esegue sia Go che Python per ogni profile e poi fa diff -r, e fallisce se c'è una qualsiasi differenza byte per byte.

Cosa fa la CI (.github/workflows/build.yml)

Struttura delle directory

gotool/           Toolchain Go (un file per comando)
profiles/         Profile dei target (un JSON per target, unica fonte di verità per il rendering)
src/              Template upstream + sorgenti dei dispositivi già renderizzati
tools/            Implementazione Python di riferimento upstream + layer di compatibilità musl/bionic + script CI
scripts/          Script upstream di campaign/misurazione (versione Go in gotool/cmd_campaign.go)
targets/          Registro dei simboli/offset del kernel per ogni target
symbols/          Tabelle dei simboli del kernel per i due profile di produzione (per gli altri target sono dati derivati)
docs/GOTOOL.md    Documentazione della toolchain Go

Confini di sicurezza

Il repository non contiene immagini firmware, chiavi del dispositivo o identificatori univoci del dispositivo. I passaggi che richiedono un'immagine kernel del produttore per essere riprodotti (estrazione dei simboli, derivazione del profile) includono l'immagine originale e non entrano nel repository.

Unica eccezione sono le tabelle dei simboli del kernel dei due profile di produzione (symbols/symbols_*.json, circa 9 MB ciascuna): build fallisce direttamente se non trova la tabella (non produce un payload con costanti non verificate), e la CI non ha l'immagine del kernel e non può ricostruire le tabelle. Contengono solo nomi di simboli e indirizzi, non l'immagine stessa.

Il payload è un root temporaneo: svanisce al riavvio, non scrive su disco, non modifica le partizioni.