TONTOU: l'attacco AMD che espone il divario tra patch Linux e disclosure dei

Il 6 agosto 2026 AMD ha pubblicato il bollettino AMD-SB-7061 sul metodo TONTOU (Time-of-Neutralization to Time-of-Use), sviluppato da Daniël Trujillo e Mengjia Yan del MIT CSAIL. Il kernel Linux conteneva già la correzione dal 2 giugno, ma la fonte non specifica se un CVE sia stato o sarà assegnato, né indica una versione kernel contenente il commit.

Il meccanismo: una corsa nei nanosecondi contro Safe RET

TONTOU sfrutta una condizione di temporizzazione nelle mitigazioni Spectre-v2 basate sulla neutralizzazione. Safe RET di AMD, analogo a eIBRS di Intel, ripulisce lo stato del branch predictor prima dell'esecuzione sensibile, assumendo che tale stato rimanga intatto fino all'utilizzo. I ricercatori dimostrano che non è così.

Il sistema è semplice nella concezione e preciso nell'esecuzione: un programma senza privilegi schedula interrupt timer durante l'esecuzione kernel. Se l'interrupt atterra nella finestra post-neutralizzazione — su Zen 2, due istruzioni per sei byte — il flusso viene reindirizzato a un interrupt handler that poisons microarchitectural states. Il risultato è l'esecuzione speculativa di gadget di disclosure con accesso alla memoria del kernel.

Secondo i dati pubblicati da Trujillo e Yan, gli interrupt atterrano nella finestra vulnerabile nel 5%-12% dei casi; con registri controllati dall'attaccante, la percentuale scende circa al 2%. Sul sistema Zen 2 con Linux 6.14.0-37 e mitigazioni Spectre-v2 attive, il misprediction rate è dello 0,75%. La demo ha rotto KASLR in 10 esecuzioni su 10 e localizzato /etc/shadow in 5 casi su 10, con una media di circa 18 minuti per tentativo.

"An attacker without any special access to read arbitrary memory from the system, including sensitive data such as hashed passwords" — Daniël Trujillo, MIT CSAIL

La sincronizzazione mancata: patch disponibile, verifica difficile

Il commit kernel "x86/bugs: Make Safe-RET robust against interrupt injection", firmato dagli ingegneri AMD Borislav Petkov e David Kaplan il 2 giugno 2026, modifica la gestione dello stato dei registri per simulare il completamento di Safe-RET senza eseguire RET dopo il ritorno dall'interrupt. Questo elimina la finestra vulnerabile.

AMD-SB-7061, pubblicato il 6 agosto 2026, conferma il problema Safe RET e le dimostrazioni su Zen 1 e Zen 2, oltre all'impatto potenziale su Zen 3 e Zen 4. Tuttavia, administrators must check by commit subject per verificare la presenza della correzione: la fonte non specifica una versione kernel contenente il commit, né se un CVE sia stato o sarà assegnato.

La disclosure ai vendor è avvenuta il 5 febbraio 2026. Tra quel momento e la pubblicazione del bollettino sono trascorsi sei mesi; la patch kernel è stata integrata a quattro mesi dal bollettino. Il divario è procedurale: la correzione esisteva, ma chi doveva verificarne la presenza non disponeva di identificatori standard.

Risposte dei vendor: tre valutazioni del rischio

Intel, attraverso Jerry Bryant, Senior Director di Intel Product Assurance and Security, afferma che il comportamento rientra negli scenari BHI/IMBTI già coperti dalle linee guida esistenti. Ha erogato un bug bounty discrezionale, ma non ritiene necessarie mitigazioni aggiuntive. I dati pubblici mostrano misprediction su Arrow Lake (0,22%) e Cascade Lake Refresh (0,037%), ma nessuna fuga end-to-end è stata dimostrata su architettura Intel.

Arm classifica il comportamento come "passive leakage", inserendolo nelle proprie linee guida Spectre-v2/BHB. Il dossier non specifica se architetture Arm siano praticamente exploitabili.

AMD ha pubblicato un bollettino dedicato; Intel e Arm hanno assorbito la questione nei rispettivi framework esistenti. Questa lettura editoriale si basa sulle dichiarazioni ufficiali riportate dalle fonti.

Il profilo del rischio: chi è esposto

L'attacco richiede esecuzione di codice locale senza privilegi e accesso ai timer di precisione. In ambienti containerizzati multi-tenant, queste condizioni potrebbero essere soddisfatte: la fonte menziona "multi-tenant container impact" come rischio, ma non conferma che qualsiasi container possa attivare l'exploit.

Per le infrastrutture cloud e virtualizzate, dove l'isolamento kernel è fondamentale, TONTOU rappresenta un riscontro concreto che le mitigazioni Spectre-v2 restano incomplete sui sistemi AMD non corretti.

Le dimostrazioni sono state condotte su Linux; il dossier non specifica se Windows sia interessato. Non emergono evidenze di sfruttamento in-the-wild.

Cosa fare adesso

Administrators must check by commit subject: cercare nel proprio kernel il commit "x86/bugs: Make Safe-RET robust against interrupt injection" di Borislav Petkov e David Kaplan, datato 2 giugno 2026. La fonte non specifica una versione kernel contenente la correzione.

Verificare se i sistemi in uso montano processori AMD Zen 1, Zen 2, Zen 3 o Zen 4. AMD-SB-7061 elenca tutte queste famiglie come interessate; le dimostrazioni end-to-end riguardano Zen 2.

Monitorare la pubblicazione del paper completo alla conferenza USENIX Security 2026 (27-29 ottobre) per dettagli operativi aggiuntivi.

Con fonti primarie limitate a un advisory vendor e copertura tecnica specializzata, alcuni dettagli operativi restano da confermare con il rilascio del paper USENIX.