.##....##.########.##......##..######.....########..#######..########.....###....##....##
.###...##.##.......##..##..##.##....##.......##....##.....##.##.....##...##.##....##..##.
.####..##.##.......##..##..##.##.............##....##.....##.##.....##..##...##....####..
.##.##.##.######...##..##..##..######........##....##.....##.##.....##.##.....##....##...
.##..####.##.......##..##..##.......##.......##....##.....##.##.....##.#########....##...
.##...###.##.......##..##..##.##....##.......##....##.....##.##.....##.##.....##....##...
.##....##.########..###..###...######........##.....#######..########..##.....##....##...

All signal, no noise, 24/7.
Built for Humans & AI Agents.

Researchers have disclosed a novel variation of the Spectre v2 vulnerability, designated Branch Target Reuse (BTR). This exploit affects systems utilizing Intel, AMD, and Arm central processing units (CPUs). The vulnerability targets the Just-in-Time (JIT) compilers that are integral to operating system kernels, web browsers, and general runtime environments.

Understanding the Branch Target Reuse Vulnerability

The research, conducted by the VUSec group at Vrije Universiteit Amsterdam in the Netherlands and Scuola Superiore Sant’Anna in Italy, centers on how modern processors manage code that changes dynamically during execution. The core concept behind the attack is that although contemporary CPUs restore coherence to the architectural code following self-modification, they do not automatically invalidate old indirect branch prediction records, or “branch targets.”

In JIT engines, these outdated predictions can persist long after the code they were designed for has been removed. This persistence allows an attacker to execute a “speculative execute-after-free primitive,” enabling them to hijack speculative execution into new code placed at obsolete memory locations. While running malicious code on a compromised machine could allow an attacker to steal highly sensitive data, such as password hashes, the researchers have stated that a complete browser exploit has yet to be developed.

Impact on Key Systems and Runtimes

Kernel and Browser Exposure

The researchers demonstrated the vulnerability using several major components, including Linux cBPF, Oracle’s GraalVM runtime, and SpiderMonkey, the JavaScript and WebAssembly engine used in Firefox. They successfully developed two end-to-end exploits targeting the Linux kernel.

The kernel exploit abuses classic BPF (cBPF). Although only highly privileged users can access the eBPF JIT, its more advanced counterpart, cBPF, can still be utilized by unprivileged programs. This technique is currently relied upon by applications like Docker and Chrome for socket filtering and packet filtering. Using modern Intel CPUs, the proof-of-concept demonstrated the ability to leak arbitrary memory, bypassing every mitigation feature that was active on the system. The researchers noted that even on fully updated systems with default security settings, their exploits could extract confidential data. In one demonstration, the attack located and leaked a root password hash after it was loaded into memory, achieving a rate of 8 bytes per second.

Browser-based runtimes are also susceptible. In Firefox, the attack could originate from a malicious website executing JavaScript code within the targeted user’s browser. The researchers pointed out that if Mozilla does not complete its site isolation feature, content from different tabs might share the attacker’s address space, thereby exposing sensitive data. Regarding GraalVM, BTR could theoretically allow an attacker to bypass the memory masking that protects the runtime’s strictest sandbox mode. While the researchers successfully demonstrated the ability to reliably reuse memory addresses, they noted that GraalVM’s own compilation and garbage collection processes erased the stale branch entries before the vulnerability could be exploited, though they added that this limitation “does not appear fundamental.”

Mitigation and Industry Response

Software and Hardware Solutions

The vulnerability primarily stems from a fundamental issue: a CPU’s branch predictor can become desynchronized from the actual code residing in memory. The researchers issued a strong warning, stating, “No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable.”

While hardware flow control protections, such as x86’s IBT and Arm’s BTI protections, make exploitation more challenging, they do not eliminate the threat entirely. Furthermore, older Intel CPUs may still permit speculative execution instructions before a security check is completed. The vulnerability was reported to the impacted chipmakers and software developers, all of whom acknowledged the findings. Current fixes, however, require software implementation.

In response, Linux kernel developers introduced a specific x86 mitigation that triggers an Indirect Branch Prediction Barrier (IBPB) across all CPU cores whenever a cBPF program is placed in a memory region previously used by another BPF code. Separately, Oracle has implemented certain mitigations, while Mozilla is currently prioritizing the completion of site isolation mechanisms over IBPB-based mitigations.

Vendor Statements

The research team confirmed the underlying vulnerability behavior across all tested CPUs from Intel, AMD, and Arm. When reached for comment, AMD stated that the paper did not reveal a new vulnerability in its products, asserting that the technique described is already mitigated by existing guidance for Spectre v2 attacks. Neither Intel nor ARM responded to requests for comment.

Hue

Written by

Hue

Hue is obsessed with GPU benchmarks and checking her crypto portfolio between gaming sessions. She writes about PC tech, games, and crypto.

+ , , ,