SoftwareNews

Branch Target Reuse: Spectre v2 flaw leaks Linux root hash

Branch Target Reuse, a confirmed Spectre v2 variant, pulled a Linux root password hash in 3 to 5 minutes on Intel. Who is exposed and which kernels fix it.

Source-based. Written from the documents, reporting and reviews linked in the text. Nothing here was tested hands-on by The Ruling Desk. How we work

False-color close-up of an Intel Core i9-13900K Raptor Lake processor die, the chip family behind one tested CPU
Photo: Fritzchens Fritz / Wikimedia Commons, CC0

Branch Target Reuse (BTR) is a new Spectre v2 attack that tricks a processor into running code that no longer exists, and its researchers used it to read the root password hash on a fully patched Intel Linux machine in 3 to 5 minutes. The work, disclosed on September 29, 2026 by the VUsec group at Vrije Universiteit Amsterdam with Scuola Superiore Sant'Anna, is confirmed by the Linux kernel, which assigned two CVEs and already ships fixes. The attacker has to be running code on your machine first, so this is a local threat, not a remote one.

Key takeaways

  • BTR is confirmed: the researchers saw the underlying CPU behavior on every chip they tested, from Intel, AMD and Arm.
  • The working exploit ran only on Intel desktop chips: the root hash leaked in 3 minutes on average on a Core i9-14900K and 5 minutes on a Core Ultra 9 285K.
  • The attacker needs unprivileged code already running on the Linux box. It is not a drive-by web attack today.
  • Linux fixed it as CVE-2026-64507 and CVE-2026-64508. Kernels 6.1.183, 6.6.145, 6.12.97, 6.18.39, 7.1.4 and 7.2 carry the fix.

What Branch Target Reuse does

Modern CPUs guess where a program will jump next so they can work ahead. They store those guesses in a branch target buffer. Spectre v2, first disclosed in 2018, showed that an attacker can poison those guesses so the CPU briefly runs the wrong code and leaves traces of secret data in its cache.

BTR finds a new way to poison them. Just-in-time (JIT) compilers, the engines that turn scripts and filters into machine code on the fly, free old code and reuse the same memory for new code. According to the research paper, CPUs keep the old jump guesses even after the code under them has changed. The researchers call the result a "speculative execute-after-free": the processor briefly jumps into the middle of the new code at the old address, which can land on bytes an attacker planted.

The Linux target is classic BPF (cBPF), the small filter language behind seccomp and socket filters, which programs such as Docker and Chrome use. Unlike the more powerful eBPF, cBPF stays available to unprivileged users by default.

Labelled die shot of an Intel Core i9-13900K showing eight Raptor Cove performance cores, Gracemont efficiency cores, caches and the GPU
Image: JmsDoug and Fritzchens Fritz / Wikimedia Commons, CC0

Which CPUs the Spectre v2 variant affects

The paper lists five tested chips. The stale-guess behavior showed up on all of them; the end-to-end Linux exploit was built and timed only on the two Intel parts.

ChipCore designWhat the researchers showed
Intel Core i9-14900KRaptor CoveRoot hash leaked in about 3 minutes
Intel Core Ultra 9 285KLion CoveRoot hash leaked in about 5 minutes
AMD Ryzen 9 7950XZen 4Stale branch guesses survive; no full exploit
Broadcom BCM2712 (Raspberry Pi 5)Arm Cortex-A76Stale branch guesses survive; no full exploit
Google Tensor G3Arm Cortex-X3Stale branch guesses survive; no full exploit

The leak is slow, about 8 bytes per second, but the team walked kernel data structures to find exactly the bytes it wanted. Turning on the kernel's optional bpf_jit_harden setting, which is off by default, did not stop it: a modified exploit still recovered the hash in about 5 minutes on both Intel chips. The demo video shows the attack walking the task list once setup finishes.

AMD told SecurityWeek that the technique is covered by its existing Spectre v2 guidance and is not a new vulnerability in its products. The paper says Arm judged that exploiting BTR on its cores did not warrant new kernel mitigations.

What an attacker needs first

This is where the threat shrinks for most people. To run the Linux exploit, an attacker must already:

  • run their own code on your machine as an ordinary user;
  • be able to install cBPF filters, which a stock Ubuntu setup allows;
  • wait for a privileged process, such as su root, to put the secret in memory.

There is no remote entry point. The researchers also built a proof of concept in Firefox's SpiderMonkey JavaScript engine, estimating tens of bytes per second on Intel, but say a complete browser exploit "requires further work". In Oracle's GraalVM, the engine's own activity wiped the stale guesses before they could be used.

Why it matters

Shared machines carry the risk: multi-user servers, build runners, CI hosts and anything that runs code from people you do not fully trust. On a single-user laptop, an attacker who can already run code has easier options than an 8-bytes-per-second side channel. The paper notes the same method can target any process's memory, not just password hashes.

Hardware vendors told the researchers that tools to stop it already exist, such as the Indirect Branch Prediction Barrier (IBPB), an instruction that flushes the CPU's jump guesses, and that the fix belongs in software.

What to update on Linux

The kernel fix is two patches published on July 25, 2026. CVE-2026-64507 makes x86 kernels issue an IBPB flush when BPF JIT memory is reused, whenever Spectre v2 mitigations are on. CVE-2026-64508 adds the generic hook that flushes predictors before that memory is reused. Both records list kernels from 5.18 onward as affected.

Kernel branchFirst fixed version
6.1 LTS6.1.183
6.6 LTS6.6.145
6.12 LTS6.12.97
6.186.18.39
7.17.1.4
Mainline7.2

Run uname -r to see your version, then install your distribution's latest kernel update and reboot. Distributions backport fixes, so a vendor kernel with an older number can still be patched; check its security notice. No one has published a measured performance cost; the researchers expect it to be acceptable because removing cBPF code is not a hot path.

Outside the kernel, Oracle randomizes JIT code-cache locations in GraalVM. Mozilla is prioritizing site isolation in Firefox rather than an IBPB flush, according to the oss-security disclosure post.

What happens next

The paper will be presented at ACM CCS 2026 in The Hague, November 15 to 19, and the team has published its code. The researchers say no current CPU keeps its branch predictor in sync with rewritten code, so expect more software patches in other JIT engines rather than a microcode fix. If you patch a fleet, also check the Cisco SD-WAN zero-day and the releases that fix it, and follow the rest on our software coverage.

Bottom line

Branch Target Reuse is a confirmed, real Spectre v2 variant, and the root-hash demo is striking, but it needs local code execution and was only completed on Intel. If you run shared Linux machines, update to a fixed kernel this week. Everyone else should take the next regular kernel update.

FAQ

Can Branch Target Reuse be exploited remotely?

Not as demonstrated. The Linux exploit needs an attacker who can already run unprivileged code on the machine. A browser version in Firefox reached proof-of-concept stage on Intel, but the researchers did not build a full browser exploit.

Are AMD and Arm computers affected?

The researchers saw stale branch guesses survive on AMD Zen 4 and Arm Cortex-A76 and Cortex-X3 chips, but built the full Linux exploit only on Intel. AMD says its existing Spectre v2 guidance covers the technique, and Arm did not see a need for new kernel mitigations.

Does turning on bpf_jit_harden protect me?

It raises the bar but did not stop the researchers, who bypassed it and still recovered the hash in about 5 minutes. The kernel update is the fix.

Filed under Software

Newsletter

New articles, in your inbox.

Free. Unsubscribe in one click. Your email is kept by beehiiv, our newsletter service, and used only for this newsletter.