Researchers have uncovered a new Spectre variant that exploits the way processors remember the locations of dynamically generated code, demonstrating that sensitive Linux memory can be exposed even when existing speculative-execution protections are enabled.
The technique, calledBranch Target Reuse (BTR), targets just-in-time compilation, the process used by browsers, language runtimes and parts of the Linux kernel to turn code into machine instructions while software is running. Its central finding is that replacing executable code does not necessarily erase the processor’s predictions about where that code used to begin.
The research team at VUSec and Scuola Superiore Sant’Anna investigated Linux’s classic Berkeley Packet Filter, Firefox’s SpiderMonkey engine and Oracle’s GraalVM. Their strongest practical result was against Linux, where they developed two end-to-end exploits and demonstrated recovery of a root password hash.
The findings warrant attention, but the scope matters: the research does not establish an equally complete attack against every evaluated runtime or processor. Linux exploitation was demonstrated, Firefox testing produced a proof of concept requiring further development, and GraalVM experiments encountered a practical obstacle.
How Old Predictions Become a New Security Problem
Modern processors improve performance by predicting what a program will do next. When execution reaches an indirect branch, whose destination is determined at runtime, the processor may begin working at a predicted destination before the correct address has been resolved.
TheLinux kernel’s Spectre documentationexplains how attackers can influence these predictions and infer sensitive information from the resulting effects on CPU caches. Incorrect speculative work is discarded from the program’s visible state, but measurable traces can remain.
BTR applies this problem to executable memory that changes over time.
A JIT engine can generate a function, execute it, discard it and later reuse the same memory region for different instructions. The old function is gone, but a branch prediction referring to its former entry point may survive. If that prediction is used again, speculative execution can enter the replacement code at an unintended position.
The distinction is between keeping executable memory coherent and keeping prediction history consistent with the current meaning of that memory. A processor may correctly recognise the replacement instructions while still predicting a destination learned when those addresses held something else.
That creates a security concern for software which assumes execution will enter generated code through a valid starting point and encounter the checks placed there.
Why JIT Compilers Are an Attractive Target
JIT compilation is widely used because it combines the flexibility of interpreted languages with the speed of native execution. Frequently used functions can be compiled, optimised and replaced as an application runs.
Those performance benefits also create a changing landscape of executable memory. A security review must therefore consider more than whether a newly generated function is safe when executed normally. It must also consider whether an obsolete prediction can enter that function partway through.
The implications extend to hardening measures inserted by a compiler. A bounds check or address-masking operation can constrain a memory access when instructions execute in their intended order. If speculative execution starts after that operation, the protection may not govern the access that follows.
This is why the BTR finding concerns the interaction between processor behaviour and runtime memory management. The presence of a JIT compiler alone does not establish a working exploit, but it creates opportunities that depend on code placement, reuse and the survival of prediction entries.
What the Linux Demonstration Shows
In the Linux demonstration, the researchers reported a leakage rate of approximately eight bytes per second. They recovered a root password hash held in the memory of an su process after initiating a root authentication attempt.
The speed is modest compared with an ordinary file transfer, but targeted disclosure does not require copying an entire machine’s memory. Small secrets can have considerable value, and locating specific data can be more important than achieving high throughput.
A password hash also needs to be described accurately. Recovering it does not reveal the plaintext password automatically, nor does the demonstration itself establish unrestricted administrative control. It exposes material that could support offline password guessing, with the outcome depending on the password and hashing scheme.
The demonstrated kernel attack requires the ability to run unprivileged code on the affected system. It should not be described as a standalone network attack that immediately compromises any internet-facing Linux server.
That prerequisite still makes the finding relevant to shared computing environments and systems that execute untrusted workloads. Local execution is a meaningful security boundary: an ordinary user or restricted process should not be able to read secrets belonging to more privileged software.
Why Restricting eBPF Does Not Settle the Question
One important distinction in the research is between extended BPF, or eBPF, and the older classic BPF, or cBPF.
The researchers explain that cBPF remains accessible to unprivileged programs through mechanisms including seccomp filtering. Consequently, an organisation cannot establish that the demonstrated attack surface is absent simply by confirming that unprivileged eBPF is restricted.
The kernel’s BPF JIT configuration documentation describes a separate hardening control, bpf_jit_harden, intended to protect against JIT spraying. Its settings distinguish between disabled hardening, hardening for unprivileged users and hardening for all users.
BTR illustrates why these controls require careful interpretation. Restricting access to one BPF interface and hardening generated instructions address related but different parts of the problem. Neither should be treated as proof that every speculative-execution route involving generated code has been closed.
For administrators, the practical question is whether their particular kernel package includes the relevant fixes, together with the vendor-supported configuration for that system.
Firefox and GraalVM Results Have Different Limits
The browser findings are significant but less complete than the Linux demonstration.
For SpiderMonkey, the researchers observed that stale predictions could survive code deallocation and reallocation on Intel processors. Their proof of concept indicated potential leakage on the order of tens of bytes per second, but they explicitly said an end-to-end browser exploit would require more work.
That is a narrower finding than a demonstrated attack stealing data from arbitrary Firefox tabs. It establishes a mechanism worth addressing without proving every step needed for a reliable browser compromise.
The GraalVM results also require qualification. The team investigated whether speculative execution could skip memory-masking instructions used to confine guest code. Although they achieved suitable address reuse, compilation and garbage-collection activity removed the prediction entries before the complete attack sequence could use them.
The researchers consider that obstacle potentially surmountable. Nevertheless, a suspected path to improved exploitation remains different from an attack already demonstrated under those conditions.
For organisations using language runtimes to execute plugins or customer-supplied scripts, the findings support reviewing runtime updates and isolation boundaries rather than assuming all evaluated platforms share the same immediate exposure.
Software Mitigations Address Code Reuse
According to the researchers’ disclosure, Linux developers introduced an x86 mitigation that issues an Indirect Branch Prediction Barrier across cores when a cBPF allocation reuses a region previously occupied by executed BPF code. The changes also discourage such reuse to reduce the need for that operation.
The project identifies two associated Linux vulnerability records: CVE-2026-64507, concerning IBPB flushing during BPF JIT allocation, and CVE-2026-64508, concerning JIT-spraying hardening.
Oracle’s response, as described by the researchers, makes reuse harder through randomisation of GraalVM JIT code-cache locations. They report that Mozilla considered IBPB-based measures while prioritising site isolation.
These approaches address different aspects of exposure: prediction barriers target stale CPU state, randomisation makes controlled placement harder, and process isolation limits which secrets share an address space with untrusted code.
The references to existing protections being bypassed describe the tested configurations before BTR-specific remediation. They should not be read as evidence that the newly introduced fixes have themselves been defeated.
What Security Teams Should Check
The immediate priority is to establish whether operating-system and runtime updates covering the disclosed issues have reached deployed systems. Distribution security notices and package changelogs are more useful for that purpose than a broad statement that a machine is “fully patched,” particularly where vendors backport fixes.
Linux provides a Spectre mitigation status interface, including /sys/devices/system/cpu/vulnerabilities/spectre_v2. That offers useful visibility into enabled protections, but checking the specific BTR fixes remains a separate task.
A reasonable risk-based assessment would give particular attention to machines where mutually untrusted users or workloads share resources, and to services that intentionally execute externally supplied code. This follows from the attack’s execution prerequisites, rather than from evidence that every such deployment is exploitable.
The broader engineering lesson is that executable memory has a security lifecycle. Allocating, replacing and freeing code can change what an address means without necessarily erasing what a processor has learned about it. BTR demonstrates why JIT runtimes and operating systems must account for that history when enforcing isolation.
