// 1 CRITICAL · 2 ZERO-DAY · 3 CVE · 3 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Ricercatori MIT CSAIL dimostrano l'attacco Interrupt Injection che bypassa Spectre v2 su processori Intel e AMD. AMD ha pubblicato il bulletin SB-7061, Intel non

I ricercatori Daniël Trujillo e Mengjia Yan del MIT CSAIL hanno presentato a Black Hat USA 2026 una tecnica di attacco, denominata INTERRUPT INJECTION, che consente a un programma Linux non privilegiato di aggirare le difese Spectre v2 su processori Intel e AMD. La disclosure ai vendor è avvenuta il 5 febbraio 2026. AMD ha riconosciuto la vulnerabilità con il bulletin AMD-SB-7061 del 6 agosto, mentre Intel ha dichiarato di non aggiungere mitigazioni. La tecnica non ha ricevuto alcun identificatore CVE, costringendo gli amministratori a verificare manualmente la presenza di una patch kernel specifica.

Punti chiave
  • Un programma Linux non privilegiato può iniettare un interrupt hardware nella finestra temporale tra sanificazione e uso del branch predictor, re-inquinando il predittore dopo che la difesa è già stata eseguita.
  • Su AMD Zen 2 con Linux 6.14 e tutte le mitigazioni Spectre v2 attive, i ricercatori hanno letto /etc/shadow in 5 su 10 tentativi con un leak di 5,47 byte/s e accuratezza del 91,97%.
  • AMD ha pubblicato il bulletin AMD-SB-7061 che elenca processori Zen 1-Zen 4 come affetti; Intel non rilascia guidance aggiuntiva, ritenendo sufficienti le misure esistenti per Spectre v2 e BHI/IMBTI.
  • La mitigazione è un commit kernel specifico del 2 giugno 2026 senza CVE associato: gli amministratori devono verificare manualmente la presenza di "x86/bugs: Make Safe-RET robust against interrupt injection".

Come funziona l'iniezione nell'intervallo di due istruzioni

La tecnica sfrutta una race condition hardware-software nella sanificazione del branch predictor. Le difese Spectre v2 — Safe-RET su AMD, eIBRS su Intel — presuppongono che l'operazione di neutralizzazione del predittore e il suo utilizzo successivo dal kernel siano atomiche. INTERRUPT INJECTION dimostra che gli interrupt hardware possono atterrare in questa finestra temporale.

Su AMD Zen 2 la finestra è di due istruzioni, sei byte. I ricercatori usano timer ad alta precisione per allineare l'interrupt, poi il gestore dell'interruzione diventa gadget di training mediante Inception (CVE-2023-20569, CVSS 4.7 MEDIUM secondo NVD), riempiendo il Return Stack Buffer con target scelti dall'attaccante. La speculazione successiva impiega il predittore "re-inquinato" per deviare l'esecuzione verso gadget di disclosure.

Gli interrupt atterrano nella finestra nel 5-12% dei casi; nel circa 2% di questi i registri risultano sotto controllo dell'attaccante. L'evasione della cache L1/L2 avviene tramite sibling hyperthread, rallentando l'esecuzione per aumentare la probabilità di successo.

"An unprivileged Linux program can time a hardware interrupt to land in the gap between a processor sanitizing its branch predictor and the kernel using it, re-poisoning the predictor after the defense has run." The Hacker News, riassumendo la ricerca MIT CSAIL

I numeri dell'exfiltrazione: 5,47 byte/s e /etc/shadow in cinque tentativi su dieci

I ricercatori hanno dimostrato un leak end-to-end su AMD Zen 2 con Linux 6.14. La velocità di esfiltrazione è di 5,47 byte/s con accuratezza del 91,97%. La lettura del file /etc/shadow è riuscita in 5 su 10 tentativi. Secondo Tom's Hardware Italia, ogni tentativo di bypass KASLR richiede circa 9 minuti.

Il tasso di misprediction rilevato varia sensibilmente tra le microarchitetture testate: 0,75% su Zen 2, 0,22% su Intel Arrow Lake, 0,037% su Intel Cascade Lake Refresh. Nessuna misprediction è stata rilevata su Zen 4 nel test specifico, sebbene AMD includa questa generazione nel bulletin di vulnerabilità. I ricercatori non hanno dimostrato un leak end-to-end su Intel, ma ritengono fattibile combinarvi lavori precedenti su gadget di disclosure.

La risposta dei vendor: AMD riconosce, Intel attende

AMD ha pubblicato il bulletin AMD-SB-7061 "Safe RET Interrupt Vulnerability" il 6 agosto 2026, elencando processori Zen 1 attraverso Zen 4 come affetti. Il commit kernel di mitigazione, datato 2 giugno 2026 e curato da Borislav Petkov e David Kaplan di AMD, descrive l'attacco in termini identici alla ricerca: "injecting interrupts while Safe-RET runs can neutralize the safe return sequence, potentially leading to data leakage through speculative execution".

Intel ha assunto una posizione diversa. Jerry Bryant, Senior Director di Intel Product Assurance and Security, ha dichiarato secondo The Hacker News che "Intel's assessment is that the behavior is related to BHI/IMBTI scenarios which are addressed by Intel's existing Spectre v2 and BHI/IMBTI guidance. Intel has not observed a real-world end-to-end attack on Intel processors and does not plan to add any additional mitigation guidance at this time." Bryant ha precisato che Intel ha erogato un discretionary bug bounty bonus, ma non ha modificato l'advisory INTEL-SA-00598 aggiornato a maggio 2025. Arm, dal canto suo, ritiene che il comportamento non dia controllo deterministico diretto sui branch target.

Perché manca un CVE è un problema operativo

L'assenza di un identificatore CVE per INTERRUPT INJECTION non è una formalità. Gli strumenti di gestione delle patch, i compliance framework e i sistemi di vulnerability management si basano su identificatori standard per tracciare lo stato di correzione. Senza CVE, un commit kernel del 2 giugno 2026 resta invisibile alle pipeline automatizzate.

Gli amministratori devono verificare manualmente la presenza del commit "x86/bugs: Make Safe-RET robust against interrupt injection" nei propri kernel. Nessuna fonte nel dossier indica in quale release stabile di Linux o in quale distribuzione questo commit sia stato incluso. Il gap di visibilità è esso stesso una vulnerabilità del processo di disclosure: ambienti che presumono di essere protetti dalle mitigazioni Spectre v2 potrebbero non esserlo, senza strumenti per rilevarlo.

Questo scenario è particolarmente critico per provider cloud multi-tenant, piattaforme CI/CD con runner condivisi, ambienti VDI e container host con kernel condiviso. In tutti questi casi, l'isolamento tra tenant o job dipende dalla effettiva efficacia delle difese Spectre v2. Se un processo non privilegiato può re-inquinare il branch predictor, il modello di minaccia sottostante a queste architetture richiede revisione.

Cosa fare adesso

  • Verificare manualmente la presenza del commit kernel "x86/bugs: Make Safe-RET robust against interrupt injection" del 2 giugno 2026 nei propri sistemi Linux, consultando i log delle modifiche della distribuzione in uso.
  • Consultare il bulletin AMD-SB-7061 per determinare se i processori Zen 1-Zen 4 in produzione rientrano nella popolazione affetta e se esistano microcode aggiornati dalla piattaforma vendor.
  • Rivalutare il modello di isolamento per carichi di lavoro multi-tenant, considerando che le mitigazioni Spectre v2 attive potrebbero non garantire protezione contro un attaccante locale con capacità di timing preciso.
  • Monitorare la pubblicazione del paper MIT CSAIL a USENIX Security e l'eventuale rilascio di un CVE retrospettivo, che permetterebbe l'integrazione nei sistemi di gestione vulnerabilità.

FAQ

L'attacco funziona da remoto?

No. Il dossier documenta esplicitamente che la tecnica richiede solo esecuzione locale non privilegiata: "needs no privileges, only local code execution".

Intel rilascerà una patch?

Allo stato attuale, Intel non prevede mitigazioni aggiuntive. La posizione ufficiale, espressa da Jerry Bryant, è che le guidance esistenti per Spectre v2 e BHI/IMBTI siano sufficienti.

Zen 4 è immune?

Non è dimostrata né confermata l'immunità. Nel test specifico dei ricercatori nessuna misprediction è stata rilevata su Zen 4, ma AMD include questa generazione nel bulletin AMD-SB-7061 come affetta.

Il caso INTERRUPT INJECTION ripropone una tensione ricorrente nella sicurezza dei processori: le mitigazioni software assumono comportamenti hardware ideali, ma i microarbitri temporali del silicio introducono finestre che il modello astratto non cattura. AMD ha scelto di patchare, Intel di osservare. Per chi gestisce infrastrutture condivise, la differenza di postura tra vendor aggiunge complessità a una verifica già complicata dall'assenza di un identificatore tracciabile.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. securityarsenal.com
  3. tomshw.it
  4. thehackernews.uk