Branch Target Reuse trasforma il codice JIT dismesso in una primitiva Spectre per sottrarre dati

I ricercatori hanno reso nota Branch Target Reuse, o BTR, una variante di Spectre v2 che sfrutta le predizioni di branch rimaste in memoria dopo la rimozione di codice compilato just-in-time.

Il team di VUSec, della Vrije Universiteit Amsterdam, e della Scuola Superiore Sant’Anna ha dimostrato la tecnica sul kernel Linux. L’exploit ha usato programmi classic BPF non privilegiati per estrarre l’hash della password di root da un processo su in esecuzione.

L’attacco sottraeva otto byte al secondo. Il recupero completo ha richiesto in media tre minuti su Intel Raptor Cove e cinque minuti su Intel Lion Cove, secondo una ricerca di cui è stato dato conto il 29 settembre 2026.

Il comportamento alla base dell’attacco è stato confermato su tutte le CPU testate di Intel, AMD e Arm. La possibilità di sfruttarlo concretamente varia però in base all’ambiente software, alla generazione del processore e alle mitigazioni attive.

Le predizioni obsolete sopravvivono al riutilizzo della memoria JIT

I processori moderni prevedono la destinazione dei branch indiretti per continuare a eseguire istruzioni senza attendere che venga determinato il target corretto. Gli attacchi della classe Spectre manipolano o sfruttano questo comportamento speculativo per accedere a informazioni che l’esecuzione architetturale non dovrebbe rendere disponibili.

BTR si concentra su ciò che accade quando la memoria eseguibile usata dal JIT viene riutilizzata.

Un motore JIT può compilare un programma, collocarne il codice macchina a un indirizzo specifico e poi liberare quella memoria. Lo stesso spazio può essere assegnato in seguito a un altro programma. Anche se i byte in memoria sono cambiati, il processore può conservare le informazioni sulla destinazione dei branch associate al codice precedente.

Di conseguenza, un branch indiretto può avviare l’esecuzione speculativa nel codice appena caricato usando un target obsoleto. Questo può puntare a una posizione imprevista o disallineata nella nuova sequenza di istruzioni.

Prima o poi l’esecuzione architetturale scarta il percorso errato. Nel frattempo, però, le istruzioni speculative possono accedere a dati sensibili e modificare la cache. Misurando gli effetti sulla cache, un attaccante può dedurre i dati un byte alla volta.

I ricercatori descrivono questo fenomeno come una primitiva speculativa di tipo use-after-free: il processore si comporta come se una vecchia relazione di flusso di controllo fosse ancora valida, anche se il codice corrispondente non esiste più.

L’exploit su Linux recupera l’hash della password di root

La dimostrazione su Linux si basava su programmi classic BPF, o cBPF, non privilegiati. I ricercatori hanno addestrato il predittore dei branch con un programma, lo hanno liberato e hanno fatto in modo che un codice diverso, compilato dal JIT, occupasse lo stesso spazio di memoria.

Hanno quindi preso di mira un processo su in esecuzione ed estratto dalla memoria l’hash della password di root. Secondo quanto riportato sulla ricerca, nello scenario testato l’exploit poteva sottrarre memoria arbitraria sui moderni processori Intel, anche su sistemi completamente aggiornati e con le impostazioni di sicurezza predefinite.

Il team ha sviluppato due exploit cBPF completi. Il primo funzionava con la configurazione predefinita; il secondo era pensato per i sistemi con il constant blinding di BPF attivo, una difesa che impedisce di inserire direttamente nel codice macchina generato costanti controllate dall’attaccante.

Per la seconda versione, i ricercatori hanno codificato le istruzioni controllate dall’attaccante negli offset dei salti. Sono comunque riusciti a recuperare l’hash della password in cinque minuti.

Ottenere un hash non equivale a ottenere la password in chiaro. L’attaccante dovrebbe decifrarlo separatamente, per esempio ricorrendo a risorse di calcolo locali o cloud. Il risultato dipende dalla robustezza della password e dall’algoritmo di hashing.

Il percorso dimostrato presuppone inoltre che l’attaccante possa eseguire programmi cBPF non privilegiati. Nell’ambiente descritto dai ricercatori, le funzionalità più avanzate del JIT eBPF richiedono privilegi, ma cBPF è ancora usato per seccomp, il filtraggio dei socket e quello dei pacchetti. Tra le applicazioni che sfruttano queste funzionalità ci sono Docker e Chrome.

Gli intervalli di versioni del kernel Linux interessati non sono stati resi noti. Gli amministratori non possono quindi determinare l’esposizione limitandosi a confrontare la versione del kernel in uso con un elenco documentato di versioni vulnerabili.

Due CVE riguardano il riutilizzo del BPF JIT e lo svuotamento del predittore

Le modifiche a Linux sono associate a CVE-2026-64507 e CVE-2026-64508. Le informazioni NVD disponibili non riportano punteggi CVSS, vettori, classificazioni CWE né gli intervalli delle versioni interessate.

CVE-2026-64507 riguarda le misure di hardening applicate quando sono attive le mitigazioni per Spectre v2. Quando la memoria del BPF JIT viene riutilizzata, il kernel esegue un Indirect Branch Prediction Barrier, o IBPB, per impedire che le predizioni obsolete vengano trasferite al codice appena scritto.

L’implementazione descritta salta lo svuotamento quando il dispatcher BPF usa già una sequenza retpoline. La modifica si applica solo se il BPF JIT è attivo ed è protetta da CONFIG_BPF_JIT, così da consentire la compilazione corretta dei kernel con CONFIG_BPF_JIT=n.

CVE-2026-64508 riguarda la gestione della memoria eseguibile da parte dell’allocatore del BPF JIT. L’allocatore raggruppa i programmi di piccole dimensioni in allocazioni più grandi e ricicla lo spazio man mano che i programmi vengono caricati e rimossi. Una predizione creata per un vecchio programma può quindi indirizzare l’esecuzione speculativa verso nuovo codice collocato allo stesso indirizzo.

La relativa misura di hardening svuota i predittori dei branch indiretti prima di riutilizzare quella memoria JIT. Secondo quanto riportato, gli sviluppatori di Linux hanno implementato una mitigazione per x86 che attiva l’IBPB su ogni core del processore quando il codice cBPF viene caricato in un’area precedentemente occupata da codice BPF.

Le correzioni sono state integrate nel kernel Linux, ma non si conoscono i numeri esatti delle versioni che le includono. Per nessuna delle due CVE risultano confermati lo stato nel catalogo Known Exploited Vulnerabilities di CISA o una scadenza per gli interventi di mitigazione, stando ai dati disponibili. Non si deve quindi descrivere l’exploit dimostrativo della ricerca come un attacco confermato in circolazione.

Firefox e GraalVM presentano ulteriori superfici d’attacco

BTR non riguarda soltanto il BPF JIT di Linux. I ricercatori hanno osservato comportamenti rilevanti anche nel motore SpiderMonkey di Firefox e in Oracle GraalVM, ma in nessuno dei due casi l’indagine ha portato a un exploit completo.

In SpiderMonkey, sui processori Intel le predizioni obsolete sopravvivevano al riutilizzo degli indirizzi del codice JIT. I ricercatori hanno stimato che una tecnica completa potrebbe sottrarre decine di byte al secondo, ma servirebbe altro lavoro per trasformare la prova di concetto in un attacco funzionante contro il browser.

Il potenziale impatto dipende anche dall’isolamento dei processi. Secondo il resoconto di SecurityWeek sui risultati, Mozilla non aveva ancora completato l’implementazione dell’isolamento dei siti. In alcune circostanze, i contenuti di schede diverse potevano quindi condividere lo stesso spazio di indirizzamento, aprendo una possibile via all’esposizione di dati tra schede. Non è stato segnalato alcun attacco completo che dimostri questo scenario.

In GraalVM, i ricercatori hanno individuato un percorso speculativo che poteva saltare un controllo della sandbox basato sul mascheramento della memoria, nella modalità più restrittiva del runtime. Sono riusciti a forzare in modo affidabile il riutilizzo degli indirizzi di memoria, ma le attività di compilazione e garbage collection eliminavano le voci obsolete del predittore dei branch prima che l’attacco potesse essere portato a termine.

Questa interferenza ha limitato l’esperimento, ma non smentisce l’esistenza della primitiva. I ricercatori non la considerano un ostacolo fondamentale. Secondo quanto riportato, Oracle ha implementato alcune mitigazioni, ma non sono state rese note le versioni esatte dei prodotti né i livelli delle patch.

Le difese hardware aumentano la difficoltà, ma non bloccano ogni percorso

Le protezioni del flusso di controllo, come Indirect Branch Tracking di Intel e Branch Target Identification di Arm, possono rendere più difficile sfruttare BTR. Non eliminano però tutte le tecniche descritte dai ricercatori.

Sui processori Intel più vecchi l’esecuzione speculativa può iniziare prima che il controllo del flusso interessato abbia effetto. Lion Cove è la prima generazione Intel che, secondo i ricercatori, non presenta questa specifica race condition.

L’assenza di race condition in IBT non garantisce comunque una protezione completa. Stando a quanto riportato, i ricercatori hanno aggirato IBT sui processori privi di race condition quando il constant blinding era disattivato. Abbinare IBT senza race condition al constant blinding offre una difesa nettamente più solida.

In generale, i produttori di CPU hanno richiamato misure già esistenti, come IBPB, sostenendo che spetta al software svuotare lo stato del predittore quando cambia la funzione della memoria eseguibile. AMD ha dichiarato che la ricerca non ha individuato una nuova vulnerabilità nei suoi prodotti e ha rimandato gli utenti alle indicazioni già pubblicate per Spectre v2. Non sono state riportate le risposte di Intel e Arm.

Gli amministratori dovrebbero dare priorità agli aggiornamenti del kernel e del firmware

Chi gestisce sistemi Linux dovrebbe installare gli aggiornamenti più recenti del kernel disponibili per la propria distribuzione, soprattutto sui sistemi che consentono l’uso di cBPF non privilegiato. In assenza di un elenco delle versioni corrette, gli avvisi delle distribuzioni sono il modo più pratico per individuare i pacchetti aggiornati.

È opportuno installare anche gli aggiornamenti del firmware e del microcodice. Potrebbero rafforzare le misure di protezione già esistenti contro l’esecuzione speculativa, anche se la soluzione pratica segnalata per il riutilizzo della memoria BPF consiste nell’attivare IBPB dal software.

I team dovrebbero verificare se i carichi di lavoro richiedono cBPF non privilegiato, in particolare sugli host multiutente o sui sistemi che eseguono codice proveniente da tenant meno fidati. Disattivare una funzionalità senza valutarne le dipendenze potrebbe compromettere i carichi di lavoro che usano seccomp o il filtraggio; ogni restrizione andrebbe quindi testata prima di essere applicata.

Non sono stati resi noti indicatori di malware specifici dell’attacco, hash di file, domini o firme di rete. Il rilevamento deve quindi concentrarsi sull’uso anomalo delle funzionalità BPF in locale, sul caricamento inatteso di programmi non privilegiati e sulle attività sospette che coinvolgono processi sensibili. Questi segnali non sono specifici di BTR, ma possono aiutare a individuare i presupposti dell’attacco dimostrato su Linux.