Google Cloud VMs on AMD Turin chips need a guest OS patch and a stop-and-start to protect against three CPU side-channel flaws, Google said this week.
The company has already applied mitigations against attacks between VMs, and between VMs and the host. Inside a VM, the flaws may let an attacker with code on the same processor core infer data from other processes or the kernel.
The affected machine series are C4D, N4D, H4D, Z4D,, and G4, including bare-metal instances of C4D and Z4D. Turin is the code name for fifth-generation AMD EPYC processors.
All three flaws are Transient Scheduler Attacks (TSA). 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. 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. Neither company reports any exploitation in its bulletins.
What Google Cloud Customers Need to Do
Google's security bulletin gives these steps for each service:
- VMs: Install your OS vendor's fix when it ships. Starting this week, the company will update the CPU information that VMs report, so a patched guest kernel can turn on its mitigations. After that update reaches a VM, stop and start it. As the company puts it: "Rebooting the guest OS isn't enough."
- Bare metal instances: If you run your own OS or hypervisor on a C4D or Z4D bare metal instance, apply your vendor's fixes when they are available.
- Hypervisors inside a VM: The same CPU information update applies, so patched guest kernels can turn on their mitigations. Stop and start the VM once the update arrives.
- 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: No action is needed.
Customers on older Rome, Milan, and Genoa processors got the same stop-and-start instruction in an earlier bulletin at the time of the original disclosure on July 8, 2025.
The company lists nothing to do in the meantime for VMs whose OS vendor has not yet shipped a fix. 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 in the Linux kernel source tree. As of today, 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.
For Turin servers on your own hardware, AMD says both platform firmware and OS updates are needed to mitigate the flaws fully. The mitigation may affect performance, and administrators should weigh the risk to their own workloads, according to its technical guidance.
The Xen Project has published hypervisor patches in its Xen advisory. It says microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23.
from The Hacker News https://ift.tt/LiUb7ZS
via IFTTT
No comments:
Post a Comment