CVE-2026-64560 — Cadeia de ferramentas + portabilidade multi-alvo

CVE-2026-64560 é um use-after-free no posix-cpu-timers do kernel Linux (corrida local sem privilégios, CVSS 3.1 = 7.8; não corrigido em 6.6.118, só corrigido em 6.6.147). Este repositório faz duas coisas: transformar a cadeia de ferramentas upstream, que só pode ser acionada por um monte de scripts Python, em um único binário Go estático, e adicionar o alvo realme RMX5010 (A16 / SM8750) que o upstream não tem.

[!WARNING] Este é código de exploit de kernel experimental. Ele pode reiniciar o dispositivo, corromper o estado do kernel ou causar perda de dados. Use apenas em dispositivos que você possui ou para os quais tem autorização explícita. Faça backup primeiro.

Alvos

Pegar artefatos prontos

Sem instalar Go, sem instalar Python:

• Release: publicada automaticamente ao criar tags v*, contém ferramentas para cada plataforma + payloads para cada alvo + SHA256SUMS.txt
• Actions artifacts: gerados a cada push para main
  • cve64560-<os>-<arch>: linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads: payloads estáticos aarch64 para cada profile (rmx5010-a16-…, op13-…, cada um em seu próprio diretório, sem mais sobrescrever uns aos outros)

O android/arm64 pode ser enviado diretamente com adb push para /data/local/tmp e executado no celular.

Compilar você mesmo

go build -o cve64560 ./gotool                 # ferramenta (Go puro, sem dependências)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # payload (requer cc)

Para uma visão geral da linha de comando, execução a seco com --dry-run e como os profiles são derivados, ver docs/GOTOOL.md.

Por que a cadeia de ferramentas é em Go

O fluxo original exigia python3 + tools/*.py + um monte de shell: a máquina de teste não tem python, e no celular menos ainda. Agora um único binário estático cobre todo o fluxo kallsyms → derive → render → patch → build → campaign, e roda em qualquer lugar para onde for compilado cruzado.

A implementação em Python não foi removida: ela permanece em tools/ como implementação de referência e base de comparação no CI, o CI executa Go e Python para cada profile e depois faz diff -r, ficando vermelho se houver qualquer diferença byte a byte.

O que o CI faz (.github/workflows/build.yml)

Diretórios

gotool/           Cadeia de ferramentas Go (um arquivo por comando)
profiles/         Profiles de alvo (um JSON por alvo, fonte única de verdade para renderização)
src/              Templates do upstream + código-fonte de dispositivo já renderizado
tools/            Implementação de referência Python do upstream + camada de compatibilidade musl/bionic + scripts de CI
scripts/          Scripts de campanha/medição do upstream (versão Go em gotool/cmd_campaign.go)
targets/          Registro de símbolos/offsets de kernel por alvo
symbols/          Tabelas de símbolos de kernel dos dois profiles de produção (os demais alvos são dados derivados)
docs/GOTOOL.md    Documentação da cadeia de ferramentas Go

Limites de segurança

O repositório não contém imagens de firmware, chaves de dispositivo ou identificadores únicos de dispositivo. Etapas que exigem imagens de kernel do fabricante para reprodução (extração de símbolos, derivação de profile) trazem a imagem original consigo e não entram no repositório.

A única exceção são as tabelas de símbolos de kernel dos dois profiles de produção (symbols/symbols_*.json, cerca de 9 MB cada): o build falha imediatamente se não encontrar a tabela (não gera um payload com constantes não verificadas), e o CI não tem a imagem do kernel em mãos para reconstruir as tabelas. Elas contêm apenas nomes de símbolos e endereços, não a imagem em si.

O payload é root temporário: perde efeito ao reiniciar, não grava em disco, não altera partições.