Skip to content

Security Independently confirmed3 publishers 2 min read Published Updated

Chipmakers leave the Branch Target Reuse fix to each JIT engine that rewrites code

Intel, AMD and Arm say their IBPB barrier can block Branch Target Reuse, a Spectre v2 variant hitting all three, if JIT software calls it. Each kernel, browser and runtime that rewrites JIT code now has to add that call itself.

The Watch · Security desk

Send a correction

What happened

  • Stale indirect-branch predictions survive after a JIT engine writes new code into old memory, letting an attacker steer speculation into the new code at outdated offsets.
  • On modern Intel CPUs, the researchers' Linux kernel exploit leaked arbitrary memory past every enabled mitigation on a fully updated system with default settings.
  • The kernel attack runs through classic BPF, which unprivileged programs can still load and which seccomp, socket filtering, Docker and Chrome still rely on.
  • A proof of concept showed stale branch entries persisting in SpiderMonkey, Firefox's JavaScript and WebAssembly engine, on Intel long enough to be reused.

Why it matters

  • Who's exposed exposure Until a host runs the patched kernel, an attacker with an unprivileged foothold on Intel Linux has a demonstrated route to reading arbitrary kernel memory.
  • Who has to decide decision Mozilla chose to finish site isolation before adding IBPB, so Firefox's defence rests on that rollout, and until it completes, content from other tabs may sit in the attacker's address space.
  • What it sets up precedent With the fix assigned to software, each JIT engine that reuses code memory needs its own barrier call, and the research examined only three engines.

Ranked by what has been demonstrated, the Linux kernel on Intel comes first. The researchers built two end-to-end exploits against it [4], and the attack starts from code already running on the target machine [13]. "Our exploit leaks 8 bytes per second. That may sound slow, but with careful pointer chasing we only need to leak a small amount of data to reach the secret," the researchers wrote [5]. Eight bytes a second is about 480 bytes a minute [22]. In their demo, that rate was enough to locate and leak the root password hash after it was loaded into memory [6].

Linux kernel developers have added the barrier on x86. The kernel now triggers an IBPB across every CPU core whenever a cBPF program is placed in a memory region that previously executed BPF code already used [7]. The report does not list a CVE identifier or disclosure dates, or describe any use of the technique outside the researchers' work.

The browser case is less developed. Attacks from malicious web pages appear feasible, but the researchers have not built a complete browser exploit [13]. They estimate SpiderMonkey could leak dozens of bytes per second, and say more work is needed to get there [16].

In GraalVM, BTR could let an attacker speculatively skip the memory masking that protects the runtime's strictest sandbox mode against Spectre [17]. The researchers reliably reused memory addresses, but GraalVM's own compilation and garbage collection erased the stale branch entries before they could be exploited [18]. The researchers said that limitation "does not appear fundamental" [18]. Oracle has rolled out some mitigations [20].

The researchers trace the problem to a branch predictor that can drift out of step with the code actually in memory [11]. "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable," they wrote [12].

What to watch

  • A complete SpiderMonkey exploit that turns the researchers' estimate of dozens of bytes per second into a working browser attack.
  • A Linux mitigation for Arm cores; the kernel change described so far covers x86.
  • A GraalVM attack that survives the runtime's garbage collection, the obstacle the researchers say is not fundamental.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence72
Adoption40
Hype gap+15
Incentives30
Confidence70

Perspective Coverage

3 publishers
Builder
Builder 42%
Operator
Operator 51%
Investor
Investor 7%
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Researchers from the VUSec group at Vrije Universiteit Amsterdam and Scuola Superiore Sant'Anna disclosed a new variant of the Spectre v2 attack affecting systems powered by Intel, AMD and Arm CPUs.

    Reported Supported Source: SecurityWeekView cited source
  2. [2]

    The variant is named Branch Target Reuse (BTR) and targets the just-in-time (JIT) compilers relied upon by operating system kernels, web browsers and runtimes.

    Reported Supported Source: SecurityWeekView cited source
  3. [3]

    In JIT engines, stale indirect branch predictions can outlive the code they were created for and be reused once new code is written to the same memory, giving a speculative execute-after-free primitive that lets an attacker hijack speculative execution into the new code at obsolete offsets.

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  4. [4]

    The researchers analyzed Linux cBPF, Oracle's GraalVM runtime and Firefox's SpiderMonkey engine, and developed two end-to-end exploits against the Linux kernel.

    Reported Supported Source: SecurityWeekView cited source
  5. [5]

    "Our exploit leaks 8 bytes per second. That may sound slow, but with careful pointer chasing we only need to leak a small amount of data to reach the secret,"

    Reported Supported Source: The researchers, quoted by SecurityWeekView cited source
  6. [6]

    In a demo, the researchers used the attack to locate and leak the root password hash after it was loaded into memory.

    Reported Supported Source: SecurityWeekView cited source
  7. [7]

    Linux kernel developers introduced an x86 mitigation that triggers an IBPB across every CPU core whenever a cBPF program is placed in a memory region already used by previously executed BPF code.

    Reported Supported Source: SecurityWeekView cited source
  8. [8]

    Classic BPF (cBPF) can still be used by unprivileged programs, unlike the eBPF JIT, and seccomp, socket filtering and packet filtering in applications like Docker and Chrome continue to rely on it.

    Reported Supported Source: SecurityWeekView cited source
  9. [9]

    The researchers confirmed the underlying behavior on every CPU they tested from Intel, AMD and Arm.

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  10. [10]

    On modern Intel CPUs the kernel exploit leaks arbitrary memory and bypasses all enabled mitigations, and according to the researchers it works even when a system is fully updated with default security settings.

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  11. [11]

    The problem stems from a CPU's branch predictor drifting out of step with the code actually in memory.

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  12. [12]

    "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable,"

    Reported Supported Source: The researchers, quoted by SecurityWeekView cited source
  13. [13]

    An attacker able to run code on a targeted machine could exploit BTR to steal data such as password hashes; attacks from malicious web pages appear feasible, but the researchers have yet to build a complete browser exploit.

    Reported Supported Source: SecurityWeekView cited source
  14. [14]

    Because Mozilla has yet to complete the rollout of site isolation, content from other tabs may share the attacker's address space in Firefox.

    Reported Supported Source: SecurityWeekView cited source
  15. [15]

    The researchers' proof of concept showed stale branch entries persist in SpiderMonkey on Intel processors long enough to be reused.

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  16. [16]

    The researchers estimate data could leak from SpiderMonkey at dozens of bytes per second, but more work is needed to build a complete browser exploit.

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  17. [17]

    In GraalVM, BTR could allow an attacker to speculatively skip the memory masking that protects the runtime's strictest sandbox mode against Spectre.

    Reported Supported Source: SecurityWeekView cited source
  18. [18]

    The researchers reliably reused memory addresses in GraalVM, but its own code compilation and garbage collection erased stale branch entries before they could be exploited; the researchers said this limitation "does not appear fundamental."

    Reported Supported Source: Researchers, via SecurityWeekView cited source
  19. [19]

    The issue was reported to affected chipmakers and software developers, all of whom acknowledged it; CPU vendors said existing mechanisms such as the indirect branch prediction barrier (IBPB) can mitigate BTR and that fixes need to be implemented in software.

    Reported Supported Source: CPU vendors, via SecurityWeekView cited source
  20. [20]

    Oracle has rolled out some mitigations.

    Reported Supported Source: SecurityWeekView cited source
  21. [21]

    Mozilla is prioritizing completion of site isolation over IBPB-based mitigations.

    Reported Supported Source: SecurityWeekView cited source
  22. [22]

    At 8 bytes per second, the Linux kernel exploit leaks about 480 bytes per minute.

    Derived Supported

Sources

3 independent publishers whose own reporting we read for this story.

  1. bleepingcomputer.com

    1 article · September 29, 2026

    New Spectre v2 attack variant leaks Linux root password hash in minutes
  2. securityweek.com

    1 article · September 29, 2026

    New Spectre v2 Variant Exposes Intel, AMD, Arm CPUs to Data Leaks
  3. thehackernews.com

    2 articles · September 30, 2026

    New Spectre-v2 BTR Attack Leaks Linux Memory Despite Existing Defenses

Topics and entities

Topics

Entities