Google Cloud Warns Three AMD Turin CPU Flaws Could Leak Data Across Processes in VMs

Google Cloud has warned that three Transient Scheduler Attacks (TSA) affect AMD Turin-based virtual machines and can let code running inside a VM infer data from other processes or the kernel. The company says it has already mitigated attacks between VMs and between VMs and hosts, while customers must apply guest OS fixes and stop and start affected instances. The affected machine series include C4D, N4D, H4D, Z4D, and G4, including bare-metal C4D and Z4D instances.

What Is Affected

Turin is the code name for fifth-generation AMD EPYC processors. The affected machine series are C4D, N4D, H4D, Z4D, and G4, including bare-metal instances of C4D and Z4D. Inside a VM, the flaws may let an attacker with code on the same processor core infer data from other processes or the kernel.

All three flaws are Transient Scheduler Attacks. Two of them, TSA-SQ (CVE-2024-36350) and TSA-L1 (CVE-2024-36357), were first disclosed on July 8, 2025, for earlier EPYC processors. AMD now says its Zen 5 processors, which include Turin, are "impacted differently from previously characterized AMD processors." The third flaw, CVE-2026-0004, is new and may let an attacker who can run code on a system infer data in the processor's L1 data cache. The Xen Project calls the new flaw TSA-Fill and says AMD had previously said Zen5 CPUs were not vulnerable to TSA-SQ and TSA-L1.

Severity and Exploitation

Google rates the issue Medium. AMD classifies all three as local attacks with high attack complexity that require only low privileges. As of today, none of the three is in the KEV catalog maintained by CISA, and neither company reports exploitation in its bulletins.

What Google Cloud Customers Need to Do

For VMs, customers should install their OS vendor's fix when it ships. Starting this week, Google will update the CPU information that VMs report, so a patched guest kernel can turn on its mitigations. After that update reaches a VM, customers must stop and start it; rebooting the guest OS is not enough.

Bare-metal C4D and Z4D customers running their own OS or hypervisor should apply vendor fixes when available. Hypervisors inside a VM follow the same CPU information update and stop-and-start requirement. For GKE, updated node images for Turin-based bare metal instances will be made available, and upgrading nodes picks up the CPU information update; as of today, the bulletin does not yet list them as available. Cloud Run requires no action. Customers on older Rome, Milan, and Genoa processors received the same stop-and-start instruction in an earlier bulletin on July 8, 2025. Google lists nothing to do in the meantime for VMs whose OS vendor has not yet shipped a fix and does not say how to tell when the CPU information update has reached a VM.

Broader Mitigation Status

A kernel commit that mitigates TSA on Zen 5, including the new variant, is in the Linux kernel source tree. As of today, Debian has fixed CVE-2026-0004 in its Linux kernel only in its unstable branch, while its security tracker still lists kernels in bookworm, trixie, and forky as vulnerable. For Turin servers on a customer's own hardware, AMD says both platform firmware and OS updates are needed for full mitigation; the mitigation may affect performance, and administrators should weigh the risk to their workloads. The Xen Project has published hypervisor patches and says microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23.

Sources: The Hacker News