Google Cloud says virtual machines on AMD Turin chips need a guest operating system patch and a stop-start cycle to reduce exposure to three CPU side-channel flaws. It says the current mitigations already cover attacks between virtual machines and between virtual machines and the host, while the inside-a-VM risk remains for an attacker running code on the same processor core.
Affected Google Cloud services and machine types
The affected machine series are C4D, N4D, H4D, Z4D, and G4. The list includes bare-metal instances of C4D and Z4D. Turin is the code name for fifth-generation AMD EPYC processors.
Google says VMs should install the OS vendor’s fix when it arrives. After the company updates the CPU information that VMs report, a patched guest kernel can turn on its mitigations, and the VM must be stopped and started once that update reaches it. The bulletin says rebooting the guest OS is not enough.
Bare-metal instances need vendor fixes on C4D or Z4D if customers run their own operating system or hypervisor there. For hypervisors inside a VM, the same CPU information update applies, and the VM must be stopped and started after the update arrives. For GKE, updated node images for Turin-based bare-metal instances will be made available, and upgrading nodes picks up the CPU information update, although the bulletin does not yet list them as available. Cloud Run needs no action.
Three Transient Scheduler Attacks on Zen 5
All three flaws are Transient Scheduler Attacks, also called TSA. Two of them are TSA-SQ, CVE-2024-36350, and TSA-L1, CVE-2024-36357. They were first disclosed on July 8, 2025, for earlier EPYC processors. AMD says its Zen 5 processors, which include Turin, are “impacted differently from previously characterized AMD processors.”
The third flaw is CVE-2026-0004, which is new. AMD says it may let an attacker who can run code on a system infer data in the processor’s L1 data cache. The Xen Project, which maintains the Xen hypervisor, calls the new flaw TSA-Fill. It also says an earlier statement has been corrected: “AMD had previously said that Zen5 CPUs were not vulnerable to TSA-SQ and TSA-L1.”
Google rates the issue Medium. AMD classifies all three as local attacks with high attack complexity that require only low privileges, according to its Zen 5 bulletin and CVE-2026-0004 advisory. As of today, none of the three is in the KEV catalog of exploited flaws kept by the U.S. Cybersecurity and Infrastructure Security Agency, and neither company reports any exploitation in its bulletins.
What Google says customers should do
For VMs whose OS vendor has not yet shipped a fix, Google lists nothing to do in the meantime. It also does not say how to tell when the CPU information update has reached a VM.
A kernel commit that mitigates TSA on Zen 5, including the new variant, is already in the Linux kernel source tree. Debian has fixed CVE-2026-0004 in its Linux kernel only in its unstable branch. Its security tracker still lists the kernels in bookworm, trixie, and forky as vulnerable.
AMD says Turin servers on customer-owned hardware need both platform firmware and operating system updates to fully mitigate the flaws. Its technical guidance says the mitigation may affect performance, and administrators should weigh the risk to their own workloads. The Xen Project says hypervisor patches are available in its Xen advisory, and microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23.
Licensed under CC BY-ND 4.0 International