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.
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.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
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
Follow any of these and your For You feed starts watching them — no settings page required.