Spectre v2 variant BTR leaks data on Intel, AMD, Arm CPUs

A newly disclosed Spectre v2 variant can pull sensitive data out of memory on systems running Intel, AMD and Arm processors. The researchers say the attack works even against fully patched machines with default security settings.

The technique, named Branch Target Reuse (BTR), was developed by the VUSec group at Vrije Universiteit Amsterdam in the Netherlands and researchers at Scuola Superiore Sant'Anna in Italy. It goes after just-in-time (JIT) compilers, which operating system kernels, web browsers and runtimes use to generate code on the fly.

An attacker who can already run code on a target machine could use BTR to read memory contents such as password hashes. The researchers believe attacks from malicious web pages are also possible, but they have not yet built a full browser exploit.

Stale predictions outlive the code

BTR abuses the way processors deal with code that is modified while it runs. Modern CPUs make sure the actual instructions in memory stay consistent after code changes itself. The branch predictor is a different story.

"The key insight behind the attack is that, while modern CPUs restore architectural code coherence after self-modification, they do not necessarily invalidate stale indirect branch prediction entries (i.e., branch targets)," the researchers explain.

In a JIT engine, these outdated entries can remain after the code they belonged to is gone. When fresh code is written to the same memory, the old predictions can be reused. The researchers call this a speculative execute-after-free primitive. It lets an attacker steer speculative execution into the new code at offsets that no longer make sense.

The team studied three targets: Linux cBPF, Oracle's GraalVM runtime, and SpiderMonkey, the JavaScript and WebAssembly engine used in Firefox.

Root password hash leaked from the Linux kernel

Two complete exploits were built against the Linux kernel, both abusing classic BPF (cBPF). Its successor, eBPF, is limited to privileged users, but unprivileged programs can still use cBPF. Seccomp, socket filtering and packet filtering in software such as Docker and Chrome still depend on it.

On modern Intel CPUs, the exploit reads arbitrary memory and gets around every enabled mitigation.

"Our exploit leaks 8 bytes per second. That may sound slow, but with careful pointer chasing we only need to leak a small amount of data to reach the secret," the researchers note. In a demonstration, they found and leaked the root password hash once it had been loaded into memory.

Firefox and GraalVM also affected

In Firefox, the attack would start on a malicious website running JavaScript in the victim's browser. Mozilla has not finished rolling out site isolation, so content from other tabs could sit in the same address space as the attacker's code.

A proof-of-concept showed that stale branch entries survive in SpiderMonkey on Intel chips long enough to be reused. The researchers estimate a leak rate of dozens of bytes per second, though a working browser exploit still needs more effort.

For GraalVM, BTR could let an attacker speculatively jump past the memory masking that guards the runtime's strictest sandbox mode against Spectre. The researchers reliably reused memory addresses, but GraalVM's compilation and garbage collection wiped the stale entries before they could be abused. They say this obstacle "does not appear fundamental."

Chipmakers point to software fixes

Affected chipmakers and software developers were notified and acknowledged the findings. CPU vendors said existing tools such as the indirect branch prediction barrier (IBPB) can mitigate BTR, and that the fixes belong in software.

Linux kernel developers added an x86 mitigation that fires an IBPB on every CPU core when a cBPF program is placed in memory previously used by executed BPF code. Oracle has shipped some mitigations. Mozilla is prioritizing finishing site isolation rather than IBPB-based fixes.

The researchers confirmed the behavior on every Intel, AMD and Arm CPU they tested. "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable," they warn.

Hardware control-flow protections, x86's IBT and Arm's BTI, make exploitation harder but do not remove the risk. Older Intel CPUs can still speculatively run instructions before the check happens. Lion Cove is the earliest Intel generation the researchers found without this race condition. Even there, they bypassed IBT when constant blinding was turned off, although they describe race-free IBT plus constant blinding as a much stronger defense.

AMD told SecurityWeek the paper did not reveal a new vulnerability in its products and that existing Spectre v2 guidance mitigates the technique. Intel and Arm did not respond.

Our Take

BTR fits a familiar pattern: years after Spectre first surfaced, researchers keep finding new ways around the mitigations that were meant to close it. The core problem here sits in hardware, yet the burden of fixing it lands on kernel, browser and runtime developers. That suggests the response will be uneven, as each project weighs performance costs differently, as Mozilla's choice to focus on site isolation shows.

For most readers, the practical step is to keep Linux kernels, browsers and runtimes like GraalVM updated as these mitigations arrive. Multi-tenant hosts where untrusted users can load cBPF filters deserve particular attention. BTR also joins other research, such as recent work showing file notification APIs leaking user activity, in reminding us that low-level system behavior can expose data in unexpected ways. It is worth watching whether a complete browser exploit appears, and whether CPU vendors eventually add a hardware mechanism to keep branch predictors in step with memory.