Security researchers have disclosed a new Spectre-v2 attack called Branch Target Reuse (BTR), showing how stale CPU branch predictions can be abused to leak sensitive data from Linux systems.
Developed by researchers from VUSec at Vrije Universiteit Amsterdam and Scuola Superiore Sant’Anna, BTR targets environments that generate code dynamically, including JIT compilers. For Linux, the team focused on classic BPF (cBPF) and built two end-to-end exploits.
The basic idea is that modern CPUs try to predict where a program will execute next to improve performance. BTR abuses cases where those predictions remain in the processor even after the original code has been removed and the same memory has been reused.
If the CPU follows an outdated prediction, it may briefly execute new code from the wrong location. That speculative execution is discarded, but traces left behind can be measured and used to recover data that should not be accessible.
In their Linux demonstration, the researchers used cBPF to read arbitrary memory on modern Intel processors. The attack reached about 8 bytes per second and extracted the root password hash from memory used by the su process.
Importantly, that does not mean BTR can remotely steal a Linux root password. The attack requires an attacker to already run unprivileged code on the target system, and the researchers extracted a password hash, not the plaintext password.
One notable detail is that disabling unprivileged eBPF does not remove this attack surface. Classic BPF is still used by Linux for features such as seccomp and socket filtering, and by software including Docker and Chrome.
The researchers also tested BTR against Firefox’s SpiderMonkey engine and Oracle’s GraalVM. In Firefox, they demonstrated the technique through WebAssembly but did not build a full browser exploit. GraalVM showed exposure to the technique, though internal runtime behavior prevented a practical attack.
According to the researchers, the CPU behavior needed for BTR was observed across tested Intel, AMD, and Arm processors. However, the complete Linux cBPF exploit targets Intel systems and should not be taken to mean the same attack works identically across all architectures.
The good news is that Linux includes mitigations for the issue. Kernel developers added protections that flush branch prediction state when BPF JIT memory is reused and introduced hardening against JIT spraying. The related fixes are tracked as CVE-2026-64507 and CVE-2026-64508.
For more information, see this LinkedIn post.
Rust would not have helped with this but it is needed to help with the never ending flood of new security issues relating to ai finding so many.
“Linus Torvalds”When I looked at the CVE feed scrolling past, I counted at least a dozen use-after-free vulnerabilities that would have been structurally impossible in Rust. That is not opinion. That is a language-level guarantee.
Microsoft, Google, and CISA have independently found that 70 to 80 percent of serious software vulnerabilities are memory safety bugs. Greg Kroah-Hartman, the stable branch maintainer who reviews every kernel CVE, has estimated that 80 percent of Linux kernel CVEs would have been impossible if the code had been written in Rust.
A good programmer have no security problems because of the used language, except that the language runtime have a security problem, not applicable to C.
Yes, but Rust isn’t finished yet. Mistakes are not systemic problems with the language (C is quite mature and has many memory safe features now), it is the problem of quality of commits.
Until we stop trying to make a language standard that doesn’t let people do bad things with sloppy code and ACTUALLY teach secure coding, this will happen.
Rust is NOT a panacea. I’m so sick and tired of hearing that. Just write better C. And stop trying to rewrite everything in Rust.
Rust will continue to be used more and more and the data proves it helps eliminate a lot of security issues. People that have coded for many years or most of there adult life will never be able to eliminate issues like memory safe languages can and there is a ton of data to prove this and it really does not matter what my opinion or yours is because the overall trend is to use safer code and its already happening and no amount of complaining will stop it. https://www.cisa.gov/news-events/alerts/2025/06/24/new-guidance-released-reducing-memory-related-vulnerabilities
Eight out of ten vulnerabilities that keep kernel developers up at night are the exact category of bugs that Rust prevents at compile time.
The April 2026 release of Linux 7.0 formalized this decision. Rust is a permanent, non-experimental part of the kernel tree. It was not a vote. It was a recognition of the reality that had already been established by the production drivers, the CVE data, and the consensus of the people who maintain the kernel.