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

CVE-2026-64560 is a use-after-free in the Linux kernel posix-cpu-timers (local unprivileged race, CVSS 3.1 = 7.8; unfixed in 6.6.118, fixed only in 6.6.147). This repository does two things: it turns the upstream toolchain, which can only be driven by a pile of Python scripts, into a single static Go binary, and it adds the realme RMX5010 (A16 / SM8750) target that upstream lacks.

[!WARNING] This is experimental kernel exploit code. It may reboot the device, corrupt kernel state, or cause data loss. Only use it on devices you own or are explicitly authorized to test. Back up first.

Targets

profile	device	kernel	status
rmx5010-a16	realme RMX5010 / RE6018L1, A16 BP2A.250605.015	6.6.118-android15-8-g93e223c276e7-abogki500782043-4k	New in this repository; the static payload passes the --preflight gate on a real device, full privilege escalation has not yet been verified on hardware
dada	Xiaomi 15	6.6.118-android15-8-gb9cc6ec16bc8-…-4k	Kept as-is from upstream (see upstream notes)
op13	OnePlus 13	Same as upstream	Kept as-is from upstream

Grab the ready-made artifacts

No need to install Go or Python:

• Release: automatically published when a v* tag is pushed, containing the tools for each platform + the payloads for each target + SHA256SUMS.txt
• Actions artifacts: produced on every push to main
  • cve64560-<os>-<arch>: linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads: the aarch64 static payloads for each profile (rmx5010-a16-…, op13-…, each written to its own directory, no longer overwriting each other)

The android/arm64 one can be adb pushed directly to /data/local/tmp and run on the phone.

Build it yourself

go build -o cve64560 ./gotool                 # tool (pure Go, no dependencies)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # payload (requires cc)

For the command-line overview, --dry-run no-op runs, and how profiles are derived, see docs/GOTOOL.md.

Why the toolchain is Go

The original workflow required python3 + tools/*.py + a pile of shell: the test machines don't have python, and the phone certainly doesn't. Now a single static binary covers the entire kallsyms → derive → render → patch → build → campaign pipeline, and it runs anywhere you can cross-compile to.

The Python implementation has not been removed: it stays in tools/ as a reference implementation and a CI parity baseline. CI runs both Go and Python for each profile and then diff -rs them, failing on any byte-level mismatch.

What CI does (.github/workflows/build.yml)

job	purpose
gotool	Cross-compiles for 5 platforms + gofmt/go vet/go test
parity	Byte-for-byte comparison of Go and Python output; hard-verifies golden artifacts against tools/golden.sha256
payload	Compiles payloads inside an arm64 Alpine container (qemu), with a toolchain of the same class as the aarch64 musl gcc used during the original on-device verification
release	Automatically publishes a Release on tag

Directory layout

gotool/           Go toolchain (one file per command)
profiles/         Target profiles (one JSON per target, the single source of truth for rendering)
src/              Upstream templates + rendered device source
tools/            Upstream Python reference implementation + musl/bionic compatibility layer + CI scripts
scripts/          Upstream campaign/measurement scripts (Go version in gotool/cmd_campaign.go)
targets/          Kernel symbol/offset records for each target
symbols/          Kernel symbol tables for the two shipping profiles (those for other targets are derived data)
docs/GOTOOL.md    Go toolchain documentation

Security boundaries

The repository does not contain firmware images, device keys, or device-unique identifiers. Steps that require a vendor kernel image to reproduce (extracting symbols, deriving profiles) come with the original image and are not committed to the repository.

The only exception is the kernel symbol tables for the two shipping profiles (symbols/symbols_*.json, about 9 MB each): build fails outright if it can't find a table (it won't emit a payload with unverified constants), and CI has no kernel Image on hand to rebuild the tables from. They contain only symbol names and addresses, not the image itself.

The payload is temporary root: it expires on reboot, writes nothing to disk, and modifies no partitions.