VUSec's BTR reuses a branch-target entry that outlives the JIT code it pointed to
VUSec disclosed Branch Target Reuse, a Spectre-v2 attack on JIT engines whose Linux exploit leaks memory at 8 bytes a second. It bypassed every enabled mitigation, and the kernel's fix had already shipped in July.
The Engineer · Build desk
What happened
- Modern processors restore architectural coherence after self-modifying code but leave the stale indirect-branch predictions that once pointed at it sitting in the predictor.
- Inside a JIT, that stale target outlives the freed code and gets reused when the cache is repopulated, so the CPU speculatively runs whatever used to live at that offset.
- VUSec analyzed Linux cBPF, Oracle's GraalVM and Firefox's SpiderMonkey, and built two full exploits against the Linux kernel.
- The Linux demo pulls the root password hash out of a running su process by walking the kernel task list and then the page tables.
- Every processor the team evaluated was affected, including Intel, AMD and Arm hardware.
Why it matters
- What it limits constraint The primitive lives in the branch predictor, not the executable code, so JIT defenses that rewrite or mask the generated code do not stop it.
- Who has to decide decision Each affected project chose its own mitigation, so a shop running these JITs has to adopt and benchmark three unrelated changes, one per runtime.
- Who's exposed exposure Until Firefox finishes deploying site isolation, a malicious page's JavaScript shares an address space with other tabs, putting their data within reach.
Next story · Invest · Oct 6
AMD stock surges as agentic AI shifts workloads from GPUs to CPUs, powering Meta's Muse and DotsConfirmed2 publishers
The kernel's answer shipped before the public write-up. BTR was privately disclosed in July [9], and Phoronix reports the Linux kernel then landed patches enabling an Indirect Branch Predictor Barrier flush on every BPF JIT allocation, plus hardening against JIT spraying [10]. Those changes were mainlined and backported to stable kernels, so the public disclosure arrives with no new kernel mitigation attached [10]. IBPB flushes the branch predictor. The stale target lives there, and software hardening inside the JIT never reaches it [2].
That gap is clearest in cBPF. The bpf_jit_harden option blinds immediate constants to block direct JIT spraying, and it is off by default [14]. Even so, VUSec got past it by encoding instructions in jump offsets, the first time that spraying technique has been applied to cBPF [14]. GraalVM goes further: its strictest sandbox masks every guest memory access so the code cannot reach outside its arena [7]. BTR gets past that too, because the speculative jump lands on the obsolete entry point before any of those checks run [3].
The working exploit is slow but sufficient. The cBPF leak runs at 8 bytes per second, and VUSec's point is that careful pointer chasing needs only a small amount of leaked data to reach the secret [5]. SpiderMonkey is earlier work. The proof of concept speculatively jumps into the WebAssembly literal pool, and on Intel the team confirmed that branch-target buffer entries survive a full deallocate-and-reallocate cycle, at an estimated tens of bytes per second; a real browser exploit still needs more work [16].
By Phoronix's account, the three affected projects took three paths. The kernel took the IBPB barrier [10]. Oracle is randomizing GraalVM's JIT code-cache locations so a freed chunk and its replacement are less likely to share an address [11]. Mozilla evaluated IBPB for SpiderMonkey and decided against it, prioritizing site isolation instead [17]. The chip vendors are pointing operators to existing mitigation mechanisms [12]. None of this material puts a performance number on any of these options.
What to watch
- Whether VUSec's SpiderMonkey proof of concept becomes a working end-to-end browser exploit.
- Published performance figures for the IBPB-on-JIT-allocation flush and GraalVM code-cache randomization.
- Whether JIT runtimes beyond the three VUSec analyzed adopt IBPB flushes or code-cache randomization.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence70
- Adoption55
- Hype gap+20
- Incentives40
- Confidence68
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Branch Target Reuse (BTR) is a new Spectre-v2 attack targeting just-in-time compilers, affecting JIT engines in web browsers, language runtimes and the operating system kernel across multiple CPU vendors.
- [2]
Modern CPUs restore architectural code coherence after self-modification but do not necessarily invalidate stale indirect branch prediction entries (branch targets).
- [3]
In JIT engines the stale branch targets can outlive the original code and be reused when the code cache is repopulated, yielding a speculative execute-after-free primitive that hijacks control flow to code at obsolete offsets and bypasses software hardening.
- [4]
VUSec's end-to-end cBPF exploit leaks arbitrary memory on modern Intel CPUs while bypassing all enabled mitigations.
- [5]
The cBPF exploit leaks 8 bytes per second, and VUSec says careful pointer chasing needs only a small amount of leaked data to reach the secret.
- [6]
In the demo VUSec leaks the root password hash from the su process by walking the Linux kernel task list backwards and then walking the page tables.
- [7]
GraalVM is Oracle's multi-language runtime that JIT-compiles code; its strictest sandbox mode is explicitly hardened against Spectre by masking every guest memory access so it cannot reach outside the sandbox arena.
- [8]
All processors VUSec evaluated were impacted, including Intel, AMD and Arm hardware.
- [9]
VUSec publicly disclosed BTR, which it had privately disclosed in July.
- [10]
In July the Linux kernel landed patches enabling an Indirect Branch Predictor Barrier (IBPB) flush on BPF JIT allocations and hardening BPF against JIT spraying; those changes were mainlined and backported to stable kernels, so no new kernel mitigation accompanies the public disclosure.
- [11]
For Oracle GraalVM, JIT code-cache locations are being randomized to hinder BTR.
- [12]
Hardware vendors are encouraging existing mitigation mechanisms.
- [13]
VUSec analyzed the attack surface of Linux cBPF, Oracle GraalVM and SpiderMonkey (the JIT engine of Firefox), and built two end-to-end exploits against the Linux kernel.
- [14]
The bpf_jit_harden option applies constant blinding to immediate values to prevent direct JIT spraying and is off by default; VUSec bypassed it by adapting a JIT-spraying technique that encodes instructions in jump offsets, applied to cBPF for the first time.
- [15]
SpiderMonkey is Firefox's JavaScript and WebAssembly engine; because Firefox has not yet fully deployed site isolation, other tabs can end up in the same address space, making their data a target.
- [16]
In the SpiderMonkey proof of concept BTR speculatively jumps into the WebAssembly literal pool for speculative arbitrary code execution; on Intel CPUs the BTB entries survived the full deallocation and reallocation cycle, at an estimated leakage rate of tens of bytes per second, and turning it into an end-to-end browser exploit requires further work.
- [17]
Mozilla evaluated IBPB-based mitigations for SpiderMonkey but is instead prioritizing work on site isolation capabilities, according to Phoronix.
Sources
2 independent publishers whose own reporting we read for this story.
- phoronix.comBranch Target Reuse, BTR: New Spectre V2 Attack Targeting JIT Compilers
1 article · September 29, 2026
- Branch Target Reuse: Spectre-v2 Attacks in JIT Engines
vusec.net
1 article · September 25, 2026
Topics and entities
Topics
- Speculative execution attacks
Entities
- Firefox
- Arm
- Branch Target Reuse (BTR)
- Oracle
- Mozilla
- GraalVM
- Indirect Branch Prediction Barrier
- Linux kernel
- AMD
- SpiderMonkey
- Intel