Skip to content

Security1 publisher2 min readPublished

BTR reads a Linux root password hash off an Intel core in minutes

VUsec and Sant'Anna researchers built BTR, a Spectre v2 variant that read a Linux root password hash off two Intel cores in three to five minutes. The Linux kernel fix is merged, and the researchers advise applying operating system and firmware updates.

The Watch · Security desk

Photograph accompanying BTR reads a Linux root password hash off an Intel core in minutes
Photo: phoronix.com

What happened

  • The two flaws are tracked as CVE-2026-64507 and CVE-2026-64508.
  • When a JIT engine frees a block of code and writes new code at the same address, the processor can retain the old indirect branch target and speculatively run the new code from it.
  • On Linux the researchers found a running su process and read the root password hash out of its memory at eight bytes per second.
  • VUsec's Cristiano Giuffrida said the field had assumed since 2018 that self-modifying-code attacks on JIT engines were impractical.

Compiled by The WatchSomething wrong?How this is made

Why it matters

  • capability BTR makes self-modifying-code transient attacks a working technique against production workloads, reopening a class of attack against JIT engines that had been set aside.
  • exposure BTR recovers a password hash, so an attacker still has to crack it offline, and whether that works depends on the hashing algorithm and how strong the password is.
  • decision cBPF constant blinding, a common hardening option, does not close BTR, so operators cannot rely on that flag as a mitigation.

Classic Spectre v2 tricks the processor into briefly running instructions at a jump destination it predicted wrongly, then reads the data those instructions touched out of the CPU cache [8]. BTR reaches that state through a JIT engine. On Linux the researchers used unprivileged classic BPF to train a branch prediction, freed the program, and dropped a different one into the same memory [10]. The stale target then sent the processor into attacker-crafted instructions at a misaligned offset, and the speculative memory access left a cache trace they read out one byte at a time [11].

The researchers, who reported the flaws to the affected vendors, completed the leak only through the Linux kernel's cBPF path [23]. In Firefox's SpiderMonkey the proof-of-concept showed stale predictions survive code reuse, but they did not build a full browser exploit [17]. In Oracle's GraalVM they found a way to speculatively skip a sandbox check, though the engine cleared the predictions before the attack could finish [18].

The behavior the attack turns on is not Intel's alone. "Indirect branch prediction is inherent to modern CPUs, and BTR exploits the desynchronization between the branch predictor and the actual state of the code," VUsec said [19]. "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable." [20] The group confirmed the same behavior "on every CPU we tested, covering Intel, AMD and Arm." [21] That covers the underlying behavior, not a finished exploit on AMD or Arm.

What to watch

  • Whether Intel, AMD or Arm ship microcode or CPU changes to resync the branch predictor with running code.
  • Whether anyone turns the SpiderMonkey or GraalVM building blocks into a working browser or sandbox exploit.
  • How fast distributions backport the cBPF fix and whether constant blinding becomes a default.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories