BTR revives Spectre v2 with a JIT attack on Linux kernels

Researchers at VUSec at VU Amsterdam, working with Scuola Superiore Sant'Anna, have published Branch Target Reuse, a new class of Spectre v2 attack aimed squarely at just-in-time compilers. The team built two working exploits against the Linux kernel, and one of them pulls the root password hash out of a live system in minutes.

Stale predictions, new code

BTR exploits a gap between two things processors are supposed to keep in sync. When a program rewrites its own code, modern CPUs restore architectural coherence, but they do not necessarily discard stale entries in the indirect branch predictor. In a JIT engine those stale targets can outlive the code that trained them and still be sitting there when the JIT code cache is refilled at the same address.

The result is a speculative execute-after-free primitive. An attacker trains the branch predictor on a block of generated code, forces that block to be freed, has a new block allocated over the same address, and then triggers the indirect branch again. The CPU takes the stale prediction and speculatively jumps to the old entry point, which is now inside different code at an obsolete offset. That lets an attacker reach misaligned gadgets or step around software hardening.

Eight bytes a second is enough

The team's Linux cBPF exploit installs a training program and a target program as seccomp filters, encodes a disclosure gadget in the immediate values of the target program, and reads the kernel back out eight bytes at a time. Slow, but sufficient: the researchers walk the kernel task list backwards through prev pointers, check each process for a matching PID, follow the mm struct into the page tables, and recover the root password hash loaded by a running su process. The demonstration runs on current Intel silicon with the usual mitigations enabled.

A second version of the attack defeats constant blinding, the hardening the Linux kernel can apply to cBPF immediates through the bpf_jit_harden option. It is off by default, but the team bypassed it anyway, which is the detail that turns a curiosity into a mitigation problem.

The attack surface is wider than the kernel. The researchers analysed Linux cBPF, Oracle GraalVM and SpiderMonkey, the JIT engine inside Firefox, and report that BTR affects JIT engines in browsers, language runtimes and the operating system kernel across multiple CPU vendors. No complete browser exploit was demonstrated, and the SpiderMonkey finding is that stale predictions survive code reuse rather than a full chain, but browsers are plainly the place where a JIT bug becomes reachable from a web page.

What is being done about it

Fixes landed in the Linux kernel ahead of publication, and are tracked as CVE-2026-64507 and CVE-2026-64508. The kernel now flushes the indirect branch predictor when cBPF JIT memory is allocated, and it gained JIT spraying hardening. Oracle is randomising the location of GraalVM's JIT code cache, and Mozilla is skipping indirect-branch-predictor mitigations in favour of prioritising site isolation, on the basis that the mitigation costs more than it buys.

The practical risk to a home user sits well below the headline. An attacker has to run code on the machine already, and a password hash is not a password. Kernel updates remain the sensible response.

Our opinion

Spectre was supposed to be the vulnerability class that hardware vendors patched into irrelevance, and BTR is a useful reminder of how thin those patches can be. The interesting part is not the exploit speed, which is a researcher demonstrating feasibility rather than an attacker's tool, but the assumption it breaks: that code reuse in a JIT is architecturally invisible. Every runtime that allocates executable memory on the fly is now on notice. Mozilla's decision to decline the mitigation and lean on site isolation is the honest engineering call, and it is also a reminder that the browser is where these arguments get settled for everyone else.

Photo by Jimmy Chan on Pexels.