VUSec beschreibt Branch Target Reuse (BTR) als Spectre-v2-Technik, die veraltete Einträge in der Sprungvorhersage ausnutzt, wenn JIT-Code freigegeben und sein Speicher wiederverwendet wird. Für den Linux-Kernel berichtet die Forschungsgruppe von zwei Proof-of-Concept-Exploits. Der ausführlich beschriebene Angriff auf den cBPF-JIT leckte auf modernen Intel-CPUs 8 Byte pro Sekunde.

Was Branch Target Reuse (BTR) ist

JIT-Engines (Just-in-time-Compiler) erzeugen Programmcode erst während der Ausführung. CPUs nutzen unter anderem den Branch Target Buffer (BTB), um Ziele indirekter Sprünge vorherzusagen. Gibt eine JIT-Engine einen Speicherbereich mit Code frei, kann dort später neuer Code liegen, während ein alter Eintrag im BTB bestehen bleibt.

BTR setzt an dieser Lücke zwischen wiederverwendetem Code und der Sprungvorhersage an. Wird der alte Vorhersageeintrag ausgewählt, kann die CPU während spekulativer Ausführung an einer veralteten Position im neuen Code weiterarbeiten. Dabei können Daten über einen Seitenkanal offengelegt werden. Für den beschriebenen Angriff muss ein Angreifer unprivilegierten Code in einer JIT-Engine ausführen können; außerdem muss der veraltete BTB-Eintrag erhalten bleiben und ausgewählt werden.

Was VUSec für Linux berichtet

VUSec zufolge entwickelte das Team zwei durchgängige Proof-of-Concept-Exploits für den Linux-Kernel. Die Forschungsgruppe beschreibt im Detail einen Angriff auf den JIT-Compiler für Classic BPF (cBPF), der cBPF-Programme als seccomp-Filter nutzt. Auf modernen Intel-CPUs erreichte dieser konkrete Proof of Concept eine Leckagerate von 8 Byte pro Sekunde.

In einer Demonstration las das Team laut VUSec einen Root-Passwort-Hash aus dem Prozess su aus. Dafür wurde der Hash zunächst durch su root in den Speicher geladen. Die Rate von 8 Byte pro Sekunde bezieht sich auf den beschriebenen cBPF-Angriff, nicht auf andere JIT-Engines.

SpiderMonkey und GraalVM

VUSec berichtet auch über Untersuchungen von SpiderMonkey, der JavaScript-Engine in Firefox, und Oracle GraalVM. Bei SpiderMonkey gelang den Forschenden ein Proof of Concept; für Intel-CPUs schätzten sie die Leckagerate auf einige Dutzend Byte pro Sekunde. Ein vollständiger, durchgängiger Browser-Exploit erforderte nach ihrer Darstellung weitere Arbeit.

Bei GraalVM beobachtete das Team wiederverwendete Speicheradressen und einen spekulativen Zugriff über eine Maskierungsoperation hinaus. In den beschriebenen Versuchen löschten jedoch Kompilierung und Garbage Collection die BTB-Einträge, bevor sie genutzt werden konnten. VUSec zufolge randomisiert Oracle die Positionen im JIT-Code-Cache, um die Wiederverwendung von Speicherbereichen zu erschweren.

VUSec zufolge erwog Mozilla IBPB-basierte Maßnahmen und stellte die Fertigstellung und Einführung von Site Isolation in den Vordergrund.

Die von VUSec beschriebene Linux-Mitigation

VUSec zufolge übernahmen Linux-Kernelentwickler eine x86-Mitigation in den Upstream-Kernel. Wenn ein cBPF-Programm einen bereits verwendeten cBPF/eBPF-Speicherbereich erneut belegt, löst die Maßnahme auf allen Kernen eine IBPB aus – eine Barriere für die Vorhersage indirekter Sprünge. Sie soll außerdem die Wiederverwendung solcher Bereiche vermeiden helfen. Laut VUSec gilt die Mitigation unabhängig davon, ob Indirect Branch Tracking (IBT) aktiviert ist. Die Forschungsgruppe verknüpft die Änderungen mit CVE-2026-64507 und CVE-2026-64508.