CVE-2026-64560 — Cadena de herramientas + portabilidad multiobjetivo

CVE-2026-64560 es un use-after-free en posix-cpu-timers del kernel Linux (carrera local sin privilegios, CVSS 3.1 = 7.8; sin corregir en 6.6.118, corregido solo en 6.6.147). Este repositorio hace dos cosas: convertir la cadena de herramientas upstream, que solo se puede manejar con un montón de scripts Python, en un único binario Go estático, y añadir el objetivo realme RMX5010 (A16 / SM8750) que upstream no tiene.

[!WARNING] Este es código de exploit de kernel experimental. Puede reiniciar el dispositivo, corromper el estado del kernel o causar pérdida de datos. Úsalo solo en dispositivos que poseas o para los que tengas autorización explícita. Haz una copia de seguridad primero.

Objetivos

Obtener artefactos ya listos

Sin necesidad de instalar Go ni Python:

• Release: se publica automáticamente al etiquetar v*, incluye las herramientas para cada plataforma + las cargas útiles de cada objetivo + SHA256SUMS.txt
• Actions artifacts: se generan en cada push a main
  • cve64560-<os>-<arch>: linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads: las cargas útiles estáticas aarch64 de cada profile (rmx5010-a16-…, op13-…, cada una escribe en su propio directorio, ya no se sobrescriben entre sí)

El de android/arm64 se puede hacer adb push directamente a /data/local/tmp y ejecutar en el teléfono.

Compilar tú mismo

go build -o cve64560 ./gotool                 # herramienta (Go puro, sin dependencias)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # carga útil (requiere cc)

Para ver la lista de comandos, la ejecución en seco con --dry-run y cómo se derivan los profiles, consulta docs/GOTOOL.md.

Por qué la cadena de herramientas es Go

El flujo original requería python3 + tools/*.py + un montón de shell: en las máquinas de prueba no hay python, y en el teléfono menos aún. Ahora un único binario estático cubre todo el flujo kallsyms → derive → render → patch → build → campaign, y se puede ejecutar en cualquier lugar al que se compile de forma cruzada.

La implementación en Python no se ha eliminado: permanece en tools/ como implementación de referencia y base de comparación en CI, CI ejecuta tanto Go como Python para cada profile y luego hace diff -r, y falla si hay la más mínima diferencia byte a byte.

Qué hace CI (.github/workflows/build.yml)

Directorios

gotool/           Cadena de herramientas Go (un archivo por comando)
profiles/         Profiles de objetivo (un JSON por objetivo, única fuente de verdad para el renderizado)
src/              Plantillas de upstream + código fuente de dispositivo ya renderizado
tools/            Implementación de referencia en Python de upstream + capa de compatibilidad musl/bionic + scripts de CI
scripts/          Scripts de campaña/medición de upstream (la versión Go está en gotool/cmd_campaign.go)
targets/          Registro de símbolos/offsets del kernel de cada objetivo
symbols/          Tablas de símbolos del kernel de los dos profiles de producción (las de los demás objetivos son datos derivados)
docs/GOTOOL.md    Documentación de la cadena de herramientas Go

Límites de seguridad

El repositorio no contiene imágenes de firmware, claves de dispositivo ni identificadores únicos de dispositivo. Los pasos que requieren una imagen de kernel del fabricante para reproducirse (extraer símbolos, derivar profiles) incluyen la imagen original, que no entra en el repositorio.

La única excepción son las tablas de símbolos del kernel de los dos profiles de producción (symbols/symbols_*.json, de unos 9 MB cada una): build falla directamente si no encuentra la tabla (no genera una carga útil con constantes sin verificar), y CI no dispone de la imagen del kernel, por lo que no puede reconstruir las tablas. Solo contienen nombres de símbolos y direcciones, no la imagen en sí.

La carga útil es root temporal: deja de funcionar al reiniciar, no escribe en disco ni modifica particiones.