Branch Target Reuse and Spectre-v2 Risk

Research

Executable memory can outlive the trust of the code that used it

Branch Target Reuse describes a Spectre-v2 technique in which an attacker trains indirect branch predictions in a JIT-compiled region, waits for that executable memory to be freed and reused, and then influences later code placed at the same virtual addresses.

The researchers analysed Linux classic BPF, Oracle GraalVM, and Firefox SpiderMonkey. Their end-to-end Linux cBPF demonstration leaked arbitrary kernel memory on a modern Intel system at about eight bytes per second, including a demonstration involving the root password hash.

Demonstrated is not the same as exploited in the wild

The project reports compatible branch-history behavior across tested Intel, AMD, and Arm processors. That does not mean every workload on every processor has the same practical exploit path, and the researchers do not report observed real-world exploitation.

Scope

Track three layers of exposure separately

Layer	What the research establishes	What defenders should avoid assuming
Processor behavior	Branch-prediction history can persist across code reuse on tested CPUs.	That every CPU and workload is equally exploitable.
Runtime design	JIT engines can reuse executable locations in ways that create a training opportunity.	That every JIT has an identical gadget or mitigation.
End-to-end exploit	Linux cBPF was used to demonstrate arbitrary kernel-memory disclosure.	That the same complete chain was demonstrated for every browser or runtime studied.

Mitigations

The fixes reduce reuse or break prediction history

Linux’s x86 response uses an indirect branch prediction barrier across cores when cBPF or eBPF executable regions are reused and discourages reuse of those regions.
The disclosure assigns CVE-2026-64507 and CVE-2026-64508 to Linux-related issues; distribution advisories and backports remain the operational source for affected versions.
Oracle randomised GraalVM code-cache locations, reducing the attacker’s ability to predict where reused code will land.
Mozilla is prioritising stronger site isolation. That is a broader containment direction, not evidence that one universal Firefox patch closes every scenario.

Defender plan

Update the layer you run, then verify the mitigation arrived

1
Inventory JIT and BPF exposure. Identify kernels, browsers, language runtimes, and services that generate or reuse executable code, especially on shared or multi-tenant systems.
2
Follow product and distribution advisories. Use vendor applicability statements and fixed-version tables rather than assuming an upstream commit maps directly to the package you run.
3
Verify the running state. Confirm the updated kernel or runtime is active after deployment, including required restarts or host reboots.
4
Reduce unnecessary attack surface. Disable unused BPF functionality where operationally safe, constrain untrusted code, and preserve browser and workload isolation boundaries.
5
Watch performance and regressions. Mitigations that flush prediction state or change code placement can carry performance cost. Measure representative workloads without using performance concerns as an indefinite exception.

Defender note

Ask whether code and prediction state share a lifecycle

JIT hardening usually focuses on permissions, writable-versus-executable transitions, and control-flow integrity. This research adds another review question: when executable memory changes hands, can microarchitectural history from its previous use still influence the next tenant or security context?