www.it-connect.fr
How BTR Can Steal the Root Password Hash from Linux in Minutes
The new BTR attack can steal the root password hash from a Linux machine equipped with a recent Intel processor in 3 to 5 minutes. This Spectre v2 variant targets JIT engines, and on the CPU side, no vendor is spared. Here’s what you need to know.
Spectre is the kind of topic that resurfaces from time to time. In April 2024, I published an article about the first native Spectre v2 exploit capable of leaking kernel memory on Linux systems with an Intel processor. That finding came from the VUSec team at the Vrije Universiteit Amsterdam. These researchers are back with a new technique called Branch Target Reuse (BTR), and the project has been published on this page.
When the CPU remembers code that no longer exists
A JIT (Just-In-Time) engine compiles code on the fly: this is the case for a browser’s JavaScript engine or the BPF JIT compiler in the Linux kernel. To save time, the processor stores the destination of indirect jumps in its Branch Target Buffer (BTB) so it can predict them the next time.
The problem is the following: when the JIT engine frees a block of code and then places a new one at the same address, the processor keeps the old prediction. The researchers describe this behavior as a speculative execute-after-free primitive: the processor speculatively executes the new code at an outdated offset, which makes it possible to redirect execution flow and read data through the cache.
For their demonstration, the researchers targeted cBPF, the classic version of BPF, which remains accessible to unprivileged users (seccomp filters, socket filters). They load an initial cBPF program to train the predictor, remove it, then place a second program at the same memory location. This second program hides malicious instructions.
The attack does not read memory directly: it infers its contents byte by byte by observing the traces left in the CPU cache. The rate is 8 bytes per second. That is slow, but there is no need to read all memory; you only need to know where to look. For their demo, here is what the researchers did: a user runs the command su root, which loads the root password hash into memory. The exploit then scans the list of processes maintained by the kernel until it finds the su process, then inspects only its memory until it finds the hash. According to the researchers, it takes an average of 3 minutes on a Raptor Cove core and 5 minutes on a Lion Cove core, the performance cores in recent Intel processor generations.
There is, however, a hardening option, bpf_jit_harden (constant blinding), which is disabled by default. It obfuscates the values inserted into the compiled code, precisely to prevent malicious instructions from being hidden there. The researchers worked around it by hiding their instructions elsewhere. So in the end, the root password hash is still recovered in less than five minutes.
This is a good reminder that a hash is not the same as a plaintext password. It is only the first step. The next step is cracking it offline, and that is not always easy. It depends on the hardware used, the algorithm used, and the strength of the password.
The two other JIT engines studied are doing better for now:
- SpiderMonkey (Firefox): the PoC shows that stale predictions survive the free-and-reallocate cycle on Intel processors, but this is not a full browser exploit.
- GraalVM (Oracle): the researchers manage to bypass the sandbox check, but the engine’s activity erases the predictions before the attack.
Intel, AMD, and Arm: the fix comes through software
In any case, VUSec confirms that this behavior is the same across all tested processors, whether from Intel, AMD, or Arm. No current chip updates its jump predictions when the code changes. "As long as manufacturers do not add one, your processor is vulnerable.", the researchers note.
For their part, CPU vendors consider that the necessary mechanisms (such as IBPB) already exist and that the fix must be implemented in software. At this stage, here is where the vendors stand:
- Linux kernel: developers have integrated a mitigation for x86 that triggers an IBPB on all cores when a cBPF program reuses a region that has already been executed. Two vulnerability IDs have been assigned: CVE-2026-64507 and CVE-2026-64508.
- Oracle: GraalVM makes reuse harder by randomizing the location of the JIT code cache.
- Mozilla: the vendor studied an IBPB-based mitigation, but is currently prioritizing the full rollout of site isolation in Firefox.
Finally, understand that this attack requires the ability to run unprivileged code on the Linux machine, and therefore to already have access. If you want to patch your Linux kernel, note that the affected kernels are those starting with version 5.18, and the fixes are included in versions 6.1.183, 6.6.145, 6.12.97, 6.18.39, 7.1.4, and 7.2.
