Google Cloud avverte sulle CPU AMD Zen 5: tre vulnerabilità espongono i dati delle macchine virtuali

In sintesi

• Google Cloud segnala tre vulnerabilità nei processori AMD EPYC di quinta generazione. CVE-2024-36350, CVE-2024-36357 e CVE-2026-0004 possono consentire la deduzione di informazioni sensibili attraverso attacchi microarchitetturali.
• Le protezioni applicate da Google non eliminano ogni rischio interno alle VM. Le mitigazioni tra macchine virtuali e host sono già attive, mentre i clienti devono aggiornare il sistema operativo guest per proteggere i processi.
• AMD distribuisce nuove mitigazioni per Zen 5. Gli interventi coinvolgono firmware, microcodice e sistema operativo. Per alcune istanze Google Cloud è necessario un arresto e riavvio completo, non un semplice reboot.

Google Cloud ha pubblicato il 10 novembre 2026 un avviso di sicurezza che riguarda tre vulnerabilità microarchitetturali nei processori AMD EPYC di quinta generazione, nome in codice Turin, utilizzati nelle infrastrutture cloud. Le falle, identificate come CVE-2024-36350, CVE-2024-36357 e CVE-2026-0004, appartengono alla famiglia dei Transient Scheduler Attacks (TSA) e possono consentire a un attaccante di dedurre informazioni riservate attraverso differenze nei tempi di esecuzione delle istruzioni. Il problema interessa componenti interni del processore, tra cui la store queue e la cache L1 dei dati, con potenziali conseguenze per l’isolamento tra processi, kernel, macchine virtuali e hypervisor. Google dichiara di avere già introdotto mitigazioni per impedire attacchi tra VM e tra VM e host. Tuttavia, la protezione completa all’interno delle singole istanze dipende dagli aggiornamenti del sistema operativo gestito dal cliente. AMD ha contestualmente pubblicato due bollettini che chiariscono l’impatto sui processori Zen 5 e le correzioni necessarie.

Google Cloud identifica tre vulnerabilità nelle CPU EPYC Turin

Il bollettino GCP-2026-081 di Google Cloud identifica tre vulnerabilità che interessano l’architettura AMD EPYC Turin. Due sono già note: CVE-2024-36350, denominata TSA-SQ, riguarda la possibilità di dedurre informazioni da precedenti operazioni di scrittura attraverso la store queue; CVE-2024-36357, denominata TSA-L1, interessa invece la cache dati di primo livello. La terza, CVE-2026-0004, introduce un ulteriore scenario di divulgazione delle informazioni attraverso la cache L1D. Google classifica complessivamente il bollettino con gravità Medium, distinguendo la possibilità di sfruttamento da scenari nei quali un aggressore possa controllare immediatamente l’infrastruttura. Le vulnerabilità richiedono condizioni tecniche specifiche e non equivalgono a un accesso remoto non autenticato.

Le macchine Compute Engine interessate sono C4D, N4D, H4D, Z4D e G4, comprese le configurazioni bare metal C4D e Z4D. Si tratta di famiglie utilizzate per carichi di lavoro differenti, dall’elaborazione general purpose alle applicazioni ad alte prestazioni. L’impatto è particolarmente rilevante negli ambienti condivisi, dove la separazione tra processi e sistemi virtualizzati costituisce una proprietà fondamentale della sicurezza. Google aveva già introdotto la serie N4D con processori AMD EPYC Turin e nuove capacità di calcolo enterprise, ampliando l’utilizzo di questa generazione di CPU nelle proprie infrastrutture.

Transient Scheduler Attacks, come funziona la fuga di dati tra processi e VM

Le vulnerabilità TSA appartengono alla categoria degli attacchi side-channel basati sull’esecuzione transitoria, nei quali il processore può utilizzare temporaneamente informazioni prima che un’operazione venga definitivamente validata. Anche quando l’esecuzione speculativa non produce modifiche visibili allo stato del programma, alcune conseguenze microarchitetturali possono influenzare i tempi di elaborazione successivi. Un attaccante in grado di eseguire codice sullo stesso sistema può analizzare queste differenze temporali e tentare di ricostruire informazioni appartenenti a contesti che dovrebbero rimanere isolati. Non significa che la memoria della vittima diventi direttamente leggibile, ma che determinate informazioni possono essere dedotte sfruttando un canale laterale.

Nel caso di TSA-SQ l’attenzione si concentra sulle precedenti operazioni di scrittura; TSA-L1 e CVE-2026-0004 riguardano invece le informazioni presenti nella cache L1D. AMD descrive possibili violazioni dei confini di riservatezza kernel-user, user-user, guest-guest e host-guest, a seconda della vulnerabilità e dell’implementazione. È una classe di problemi già emersa con VMScape, l’attacco Spectre che aveva dimostrato la possibilità di sottrarre informazioni dall’host attraverso una VM AMD. Le due ricerche non descrivono lo stesso difetto, ma evidenziano quanto sia complesso garantire l’isolamento quando processi e macchine virtuali condividono risorse fisiche del processore.

Leggi anche: Interrupt Injection aggira le difese Spectre v2 sui processori AMD e Intel

AMD corregge la valutazione su Zen 5 e pubblica nuove mitigazioni

Il bollettino AMD-SB-7073 modifica il quadro precedentemente noto delle vulnerabilità TSA. Il produttore spiega che ulteriori indagini hanno dimostrato che Zen 5 è interessata dalle falle in modo diverso rispetto alle generazioni analizzate in precedenza, rendendo necessari aggiornamenti aggiuntivi del firmware Platform Initialization e del sistema operativo. Le vulnerabilità CVE-2024-36350 e CVE-2024-36357 ricevono entrambe un punteggio CVSS 3.1 pari a 5,6. Nel documento AMD Transient Scheduler Attacks for Zen 5 vengono elencate numerose famiglie interessate: EPYC 4005, 8005 e 9005, diverse linee EPYC Embedded e processori Ryzen 9000, Ryzen AI 300 e 400, Ryzen AI Max e Threadripper PRO 9000 WX. L’elenco delle mitigazioni distingue le singole famiglie e non implica che tutte siano affette in modo identico da entrambe le vulnerabilità.

Per EPYC 8005 e 9005, AMD indica il firmware TurinPI_1.0.0.B, distribuito agli OEM con data di riferimento 10 luglio 2026, insieme alla necessità di aggiornamenti del sistema operativo. Per la serie EPYC 9005 compare anche il firmware SEV 1.3A.05 per la mitigazione pertinente. Le date riportate dal produttore riguardano la disponibilità dei pacchetti ai costruttori e non garantiscono che tutti i server o computer commercializzati abbiano già ricevuto il BIOS corretto. Gli amministratori devono verificare gli aggiornamenti effettivamente pubblicati dal produttore della macchina.

CVE-2026-0004 espone la cache L1D: gravità CVSS 5.7

Il secondo documento, AMD-SB-3055, riguarda specificamente CVE-2026-0004, classificata con punteggio CVSS 4.0 di 5,7. La vulnerabilità può permettere a un attaccante che dispone della capacità di eseguire codice sul sistema di dedurre informazioni contenute nella cache L1D, superando determinati confini di privilegio. La valutazione del rischio richiede quindi di considerare sia la presenza di un processore vulnerabile sia l’effettiva possibilità di eseguire codice nelle condizioni necessarie allo sfruttamento. AMD indica come interessati EPYC 8005 e 9005 e alcune famiglie embedded, con mitigazioni che coinvolgono firmware e microcodice. Per EPYC Turin, il produttore associa la correzione al pacchetto TurinPI_1.0.0.B e richiede aggiornamenti software per Linux, Windows e VMware.

CVE-2026-0004 non deve essere automaticamente estesa a tutte le CPU Ryzen citate nel bollettino AMD-SB-7073: i due advisory hanno elenchi di prodotti interessati differenti. Per gli utenti consumer che possiedono un processore Ryzen Zen 5, la verifica deve partire dal modello esatto e dalla versione BIOS rilasciata dal produttore del computer o della scheda madre. Anche nei sistemi desktop, infatti, un aggiornamento del sistema operativo potrebbe non essere sufficiente senza la componente firmware richiesta dalla mitigazione specifica.

Google protegge gli host cloud, ma i clienti devono aggiornare i sistemi guest

Google dichiara di avere già applicato le mitigazioni necessarie a proteggere i confini tra macchine virtuali e tra macchine virtuali e host fisico. Questo non significa però che ogni rischio sia stato eliminato all’interno delle istanze. Gli attacchi tra processi appartenenti alla stessa VM richiedono protezioni che dipendono dal sistema operativo guest. Dal 10 novembre Google ha iniziato ad aggiornare le informazioni sulle funzionalità della CPU esposte alle VM, consentendo ai kernel corretti di riconoscere e attivare le mitigazioni necessarie. Gli amministratori devono quindi installare gli aggiornamenti forniti dal produttore del sistema operativo.

Il passaggio operativo più importante è che un semplice riavvio del sistema guest non basta. Dopo che l’aggiornamento delle informazioni CPU è diventato disponibile per l’istanza, Google richiede di arrestare e riavviare completamente la macchina virtuale attraverso l’infrastruttura Compute Engine. La stessa indicazione interessa le configurazioni con virtualizzazione nidificata. Per le istanze bare metal gestite autonomamente occorre invece applicare le correzioni del sistema operativo o dell’hypervisor installato dal cliente. In Google Kubernetes Engine sono previste nuove immagini dei nodi per le configurazioni bare metal Turin, mentre per Cloud Run non è richiesta alcuna azione. È una distinzione fondamentale: aggiornamenti hardware, hypervisor e kernel operano a livelli differenti e devono essere coordinati.

Le vulnerabilità hardware riaprono il problema dell’isolamento nel cloud

Le nuove segnalazioni mostrano che la sicurezza dei servizi cloud dipende tanto dal codice applicativo quanto dalle proprietà microarchitetturali dei processori utilizzati. Un sistema operativo aggiornato può correggere numerosi errori software, ma non può eliminare autonomamente ogni comportamento della CPU che consente di dedurre informazioni attraverso cache e strutture condivise. Lo stesso problema dell’isolamento aveva assunto una dimensione differente con RMPocalypse, la vulnerabilità che metteva in discussione le garanzie di integrità delle VM AMD SEV-SNP. Le tecniche e gli impatti non sono equivalenti, ma entrambe le vicende ricordano che la protezione dei dati durante l’elaborazione richiede verifiche che attraversano hardware, firmware, hypervisor e software.

Per le organizzazioni che utilizzano istanze EPYC Turin, la priorità consiste nell’identificare le famiglie Compute Engine interessate, verificare le protezioni applicate da Google e programmare gli aggiornamenti dei sistemi guest. Per gli ambienti on-premise, la gestione coinvolge invece i produttori dei server e delle piattaforme di virtualizzazione, che devono distribuire BIOS, firmware e aggiornamenti compatibili.

Continua con: DDRop mette alla prova la protezione della memoria cifrata di Intel TDX e AMD SEV-SNP

La patch del cloud non sostituisce gli interventi dentro le macchine virtuali

Il punto decisivo del bollettino GCP-2026-081 è la separazione delle responsabilità tra provider e cliente. Google può proteggere l’infrastruttura condivisa e aggiornare le informazioni CPU esposte alle istanze, ma la sicurezza dei processi in esecuzione all’interno di una VM richiede un sistema operativo correttamente aggiornato. AMD, dal canto suo, deve fornire le mitigazioni firmware e microcodice attraverso la filiera dei produttori hardware. Le vulnerabilità hanno gravità moderata e richiedono condizioni di sfruttamento specifiche; i bollettini esaminati non documentano una campagna di attacchi attiva. Non rappresentano quindi la prova di una compromissione diffusa di Google Cloud, ma un richiamo concreto alla necessità di coordinare gli aggiornamenti nei diversi livelli dell’infrastruttura. Per gli amministratori, la misura più importante è evitare di considerare protetta un’istanza soltanto perché il cloud provider ha già aggiornato i propri host.