Branch Target Reuse: Spectre v2 Flaw Leaks Linux Root Hash

Researchers have disclosed Branch Target Reuse, a new Spectre v2 variant that recovers a Linux root password hash in minutes. VUsec and Scuola Superiore Sant’Anna built the attack and tested it against Firefox’s SpiderMonkey engine, Oracle GraalVM, and the Linux kernel’s classic BPF path.

The attack requires no special privileges. An unprivileged local user can train the processor’s branch predictor, then abuse leftover prediction data after a just-in-time engine frees and reuses code memory.

For enterprise security teams, this matters because it bypasses assumptions that have held since 2018. Researchers previously believed self-modifying JIT code made this class of speculative execution attack impractical. BTR shows that assumption no longer holds.

How Branch Target Reuse breaks JIT code isolation

Branch Target Reuse targets a timing gap between JIT-compiled code and the CPU’s branch predictor. The mechanism works in stages:

• A JIT engine allocates a code chunk, and the attacker trains an indirect branch to jump to it.
• The engine frees that chunk and allocates a new one at the same memory address.
• The CPU’s branch predictor still holds the old, now-stale target for that address.

On the next indirect branch, the CPU speculatively executes the new code at the old, misaligned offset before it restores correct execution.

VUSec’s Cristiano Giuffrida told BleepingComputer that BTR proves self-modifying code does not block this attack class, contrary to prior assumptions. The researchers confirmed the underlying branch-predictor desynchronization on Intel, AMD, and Arm processors.

Recovering a root password hash from a live process

The Linux proof of concept uses unprivileged classic BPF (cBPF) programs, which remain available to non-root users even though the more powerful eBPF JIT is privilege-restricted. The researchers explain that cBPF’s simplicity, limited to two registers and forward jumps only, is why it was historically treated as safe for filters used by Docker, Chrome, and network packet filtering.

Their exploit chain works like this:

• Install a training cBPF program as a seccomp filter to prime the stale branch target.
• Remove that program and install a second cBPF program in the same memory region.
• Trigger the stale prediction to speculatively execute attacker-crafted bytes at a misaligned offset.
• Read the resulting cache timing pattern to infer memory contents one byte at a time.

The researchers walked the kernel’s task list to locate a running su process, then leaked its page tables to extract the root password hash. The technique recovers data at eight bytes per second. VUsec reported an average recovery time of three minutes on Intel’s Raptor Cove and five minutes on Lion Cove.

The attack also defeats bpf_jit_harden, the kernel’s constant-blinding option. Researchers adapted a 2016 jump-offset encoding technique to hide attacker-controlled bytes inside forward-jump offsets instead of immediate values, still recovering the hash within five minutes with hardening enabled.

Setting kernel.unprivileged_bpf_disabled=1 blocks this specific attack path, since it removes unprivileged users’ access to the cBPF training step the exploit depends on. This sysctl change works as an immediate stopgap before kernel patches land, not a permanent replacement for them.

Leaking a hash is not the same as obtaining a plaintext password. An attacker still needs to crack that hash offline, and success depends on the hashing algorithm and password strength.

Exposure beyond Linux stays limited so far

The researchers also tested two non-Linux JIT engines:

• Firefox SpiderMonkey: Proof-of-concept work confirmed stale branch predictions survive code reuse and could reach WebAssembly literal pools. Researchers did not build a complete browser exploit.
• Oracle GraalVM: Researchers found a way to skip a sandbox masking check speculatively, but GraalVM’s own compilation and garbage-collection activity cleared the stale predictions before they could complete an attack in testing.

Vendor fixes and remaining gaps

The Linux kernel team assigned two identifiers to the disclosed fixes. CVE-2026-64507 covers a new IBPB flush issued when the x86 BPF JIT reuses memory. CVE-2026-64508 covers the underlying hardening support that flushes branch predictors on JIT memory reuse. Third-party trackers currently list differing preliminary severity scores for these entries, and NVD’s own analysis remains pending, so treat published scores as provisional rather than final.

Other affected vendors took different paths. Oracle addressed its exposure by randomizing GraalVM’s JIT code-cache locations, which reduces the chance of address reuse. Mozilla considered IBPB-based mitigations for SpiderMonkey but is currently prioritizing the completion and deployment of site isolation.

VUSec’s own guidance flags limits to existing hardware defenses:

• Indirect Branch Tracking and Branch Target Identification raise the bar but do not eliminate the risk.
• Older Intel chips can still execute one or more instructions speculatively before those checks apply.
• Lion Cove is the first Intel generation VUSec found to close that race window.

Featured resource

Cybersecurity kit

Cybersecurity kit with blueprint, framework guide, checklist, incident policy template, and UEM infographic included.

DOWNLOAD

Patch and endpoint Hardening Guidance

Fixing this exposure means updating the Linux kernel itself, not just patching applications running on top of it. Distinguish two separate hardening tasks:

• Server and workstation kernels: Apply the latest kernel update containing the IBPB flush mitigation as soon as your distribution ships it.
• Interim exposure reduction: Audit kernel versions across Linux endpoints via your UEM or MDM console to find unpatched systems, and where patching is delayed, disable unprivileged BPF with sysctl kernel.unprivileged_bpf_disabled=1 to block the cBPF training path the exploit relies on.

Endpoint patch hygiene on admin or developer laptops does not remediate this flaw by itself. The exposure lives in the kernel and JIT engines running on every affected machine, so teams need visibility into kernel version and patch status across the full Linux fleet, not just perimeter systems.

Conclusion

Branch Target Reuse shows that speculative execution risk did not disappear with earlier Spectre mitigations. A local, unprivileged user can still recover a Linux root password hash in minutes using nothing more than standard cBPF programs.

Security teams should treat kernel and firmware updates as the priority fix, not an optional hardening step. Reducing local attack surface on Linux endpoints and tracking patch status across the fleet further limits exposure while vendor fixes for browser and runtime JIT engines continue to develop.