Branch Target Reuse Spectre v2 variant affects Intel, AMD, Arm

Researchers at the VUSec group at Vrije Universiteit Amsterdam and Scuola Superiore Sant’Anna disclosed Branch Target Reuse (BTR), a variant of Spectre v2 that can expose sensitive memory on Intel, AMD and Arm processors. The flaw targets just-in-time (JIT) compilers used in operating system kernels, web browsers and runtime systems.

The researchers found that processors can restore code coherence after code changes but do not always clear outdated indirect branch prediction entries. In JIT engines, those stale branch targets can be reused when new code is written to the same memory. The paper states: “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.” That reuse creates a speculative execute-after-free primitive that can redirect speculative execution into new code at obsolete offsets and expose data held in memory.

The team analyzed Linux classic BPF (cBPF), Oracle’s GraalVM runtime and SpiderMonkey, Mozilla’s JavaScript and WebAssembly engine. They produced two end-to-end exploits against the Linux kernel that demonstrated leaking the root password hash after it was loaded into memory. The kernel exploits abuse cBPF, which is available to unprivileged programs and is used by seccomp, socket filtering and packet filters in software such as container and browser platforms.

On modern Intel processors the proof-of-concept can read arbitrary memory and bypass currently enabled mitigations. The researchers reported an extraction rate of about eight bytes per second and noted that targeted pointer chasing can reduce the amount of data needed to locate secrets. They wrote that attacks launched from malicious web pages appear feasible but that a complete browser exploit has not yet been built.

In Firefox’s SpiderMonkey engine stale branch entries persisted long enough on Intel chips to be reused; the researchers estimate a potential leak rate on the order of dozens of bytes per second if a full exploit were developed. In GraalVM they could reliably reuse memory addresses, but the runtime’s compilation and garbage collection erased stale entries before exploitation in current proofs. The researchers said that limitation does not appear fundamental.

Chipmakers and software vendors were notified. CPU vendors pointed to existing mitigations such as the indirect branch prediction barrier (IBPB) and said fixes must be implemented in software. Linux developers added an x86 mitigation that issues an IBPB across all cores when a cBPF program occupies memory previously used by BPF code. Oracle deployed mitigations for GraalVM, and Mozilla is prioritizing the rollout of site isolation over IBPB-based countermeasures for SpiderMonkey. AMD responded that the paper does not describe a new vulnerability for its products and that the technique is covered by existing Spectre v2 guidance. Intel and Arm did not provide comment by the time of reporting.

The researchers confirmed the underlying behavior on all tested Intel, AMD and Arm processors, saying branch predictors can fall out of sync with the code in memory and that no current CPU provides a mechanism to fully keep them in sync. They noted that hardware control-flow protections such as x86 Indirect Branch Tracking (IBT) and Arm Branch Target Identification (BTI) increase the difficulty of exploitation but do not fully eliminate the threat. The team identified Lion Cove as the earliest Intel microarchitecture free of the race condition, and they reported ways to bypass IBT when constant blinding was disabled. Race-free IBT combined with constant blinding is described as a stronger defense.