CVE-2026-64560 — Chaîne d'outils + portage multi-cibles

CVE-2026-64560 est un use-after-free dans posix-cpu-timers du noyau Linux (race locale non privilégiée, CVSS 3.1 = 7.8 ; non corrigé en 6.6.118, corrigé seulement en 6.6.147). Ce dépôt fait deux choses : transformer la chaîne d'outils amont, pilotable uniquement via une flopée de scripts Python, en un seul binaire Go statique, et ajouter la cible realme RMX5010 (A16 / SM8750) absente en amont.

[!WARNING] Ceci est du code d'exploit noyau expérimental. Il peut redémarrer l'appareil, corrompre l'état du noyau ou entraîner une perte de données. Ne l'utilisez que sur des appareils que vous possédez ou pour lesquels vous disposez d'une autorisation explicite. Sauvegardez d'abord.

Cibles

Récupérer directement les artefacts prêts à l'emploi

Pas besoin d'installer Go ni Python :

• Release : publiée automatiquement lors du tag v*, contient les outils pour chaque plateforme + les charges pour chaque cible + SHA256SUMS.txt
• Actions artifacts : générés à chaque push sur main
  • cve64560-<os>-<arch> : linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads : les charges statiques aarch64 de chaque profile (rmx5010-a16-…, op13-…, chacune dans son propre répertoire, plus d'écrasement mutuel)

Celui en android/arm64 peut être directement adb push vers /data/local/tmp pour s'exécuter sur téléphone.

Compiler soi-même

go build -o cve64560 ./gotool                 # outil (pur Go, sans dépendances)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # charge (nécessite cc)

Aperçu de la ligne de commande, exécution à vide avec --dry-run, comment les profiles sont dérivés : voir docs/GOTOOL.md.

Pourquoi la chaîne d'outils est en Go

Le processus d'origine nécessitait python3 + tools/*.py + une flopée de shell : pas de python sur les machines de test, encore moins sur téléphone. Désormais un seul binaire statique couvre tout le flux kallsyms → derive → render → patch → build → campaign, et fonctionne partout où on peut compiler en croisé.

L'implémentation Python n'a pas été supprimée : elle reste dans tools/ comme implémentation de référence et base de comparaison pour la CI, la CI exécute Go et Python pour chaque profile puis fait un diff -r, et passe au rouge à la moindre différence d'octet.

Ce que fait la CI (.github/workflows/build.yml)

Arborescence

gotool/           chaîne d'outils Go (un fichier par commande)
profiles/         profiles de cible (un JSON par cible, source unique de vérité pour le rendu)
src/              templates amont + sources d'appareils déjà rendues
tools/            implémentation Python de référence amont + couche de compatibilité musl/bionic + scripts CI
scripts/          scripts de campagne/mesure amont (version Go dans gotool/cmd_campaign.go)
targets/          enregistrement des symboles/offsets du noyau pour chaque cible
symbols/          tables de symboles noyau des deux profiles livrés (les autres cibles relèvent de données dérivées)
docs/GOTOOL.md    documentation de la chaîne d'outils Go

Périmètre de sécurité

Le dépôt ne contient pas d'images de firmware, de clés d'appareil ni d'identifiants uniques d'appareil. Les étapes nécessitant une image noyau constructeur pour être reproduites (extraction de symboles, dérivation de profile) embarquent l'image d'origine, hors dépôt.

La seule exception concerne les tables de symboles noyau des deux profiles livrés (symbols/symbols_*.json, environ 9 Mo chacune) : build échoue directement si la table est introuvable (pas de charge avec des constantes non vérifiées), et la CI ne dispose pas de l'Image noyau pour reconstruire ces tables. Elles ne contiennent que des noms de symboles et des adresses, pas l'image elle-même.

La charge est un root temporaire : elle expire au redémarrage, n'écrit rien sur disque et ne modifie aucune partition.