Google published guidance this week for three CPU side-channel flaws affecting cloud VMs running on AMD Turin processors, and the instruction that will trip people up is buried in the middle.

You need to patch the guest OS. Then you need to stop and start the VM. As Google puts it, rebooting the guest OS is not enough.

That distinction matters because a reboot is the reflex. It clears state, reloads the kernel, and feels like a fresh start. But the mitigation here depends on CPU information that the hypervisor reports to the guest, and that information only refreshes when the instance itself is stopped and started.

What the Three Flaws Are

All three are Transient Scheduler Attacks, or TSA.

The new one, CVE-2026-0004, may let an attacker who can already run code on a system infer data sitting in the processor's L1 data cache.

The Corrected AMD Statement

This is the detail the security community noticed.

AMD now says its Zen 5 processors, which include Turin, are "impacted differently from previously characterized AMD processors."

The Xen Project, which maintains the Xen hypervisor, was more direct about what changed. It says AMD had previously said that Zen 5 CPUs were not vulnerable to TSA-SQ and TSA-L1. That statement has been corrected.

For anyone who made a deployment decision on the strength of the original claim, the correction is the part worth re-reading.

What Google Already Mitigated

Worth being precise about the remaining risk, because it is narrower than it sounds.

Google says it has already applied mitigations against attacks between VMs, and between VMs and the host. The exposure that remains is inside a VM, where the flaws may let an attacker with code on the same processor core infer data from other processes or from the kernel.

So the threat model here is not a malicious tenant reaching across a hypervisor boundary. It is a compromised process on your own instance reaching for data belonging to another process on the same instance.

That is still worth patching for. It is just a different problem than cross-tenant exposure.

Which Machine Types Are Affected

The affected Google Cloud machine series are:

• C4D
• N4D
• H4D
• Z4D
• G4

That includes bare-metal instances of C4D and Z4D.

Turin is the codename for fifth-generation AMD EPYC processors.

What Customers Need to Do, by Service

Google's bulletin breaks the guidance out by service, and the requirements differ.

Google says it will begin updating the CPU information that VMs report starting this week. That update is the trigger. A patched guest kernel can only turn on its mitigations once it sees the corrected CPU information.

The Gap Nobody Has Closed

Two things are missing from the guidance.

Google lists nothing to do in the meantime for VMs whose OS vendor has not shipped a fix. And it does not say how to tell when the CPU information update has reached a particular VM.

That second gap is the practical problem. Without a way to confirm the update landed, administrators are left stopping and starting instances on faith, or scripting a broad restart and hoping it caught everything.

The Upstream Status

A kernel commit that mitigates TSA on Zen 5, including the new variant, is in the Linux kernel source tree.

Distribution coverage is thinner. As of the bulletin, Debian had fixed CVE-2026-0004 in its Linux kernel only in the unstable branch. Its security tracker still listed 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. Its technical guidance notes that the mitigation may affect performance, and that administrators should weigh the risk to their own workloads.

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.

The Severity Picture

Google rates the issue Medium. AMD classifies all three as local attacks with high attack complexity that require only low privileges.

Neither company reports any exploitation. None of the three appears in CISA's Known Exploited Vulnerabilities catalog as of publication.

That combination, local only, high complexity, no known exploitation, is why this is not a drop-everything patch. It is why the correct response is a scheduled stop-and-start rather than an emergency one.

What Administrators Should Do

• Identify affected instances. C4D, N4D, H4D, Z4D, and G4, including C4D and Z4D bare metal. Check your inventory before you schedule anything.
• Patch the guest OS first. A stop-and-start without the patch does nothing. The kernel needs to know how to use the corrected CPU information.
• Then stop and start, not reboot. This is the step that gets missed. A guest OS reboot does not refresh the CPU information the hypervisor reports.
• Schedule it as maintenance. Given Medium severity, no known exploitation, and local-only scope, a planned window is the right approach. Coordinate the stop-and-start across dependent services.
• Track distro availability. Debian has fixed it only in unstable. If you are on bookworm, trixie, or forky, the kernel fix is not there yet.
• For bare metal, plan firmware as well. AMD says both platform firmware and OS updates are required for a full mitigation.
• Expect a performance impact. AMD's guidance says the mitigation may cost performance. Measure it on a representative workload before rolling out broadly.
• Watch for the GKE node images. Google said they will be made available. As of the bulletin, they were not listed.
• Confirm the CPU information update before restarting. Google has not published a method for this. Build your own check, or accept the uncertainty and restart the full affected set.

Why the Stop-and-Start Distinction Exists

A VM's guest OS learns what CPU it is running on at boot, and the hypervisor supplies that information. Changing what the hypervisor reports to a running guest requires the guest to re-read it, which means the instance has to be stopped and started rather than simply restarted from inside.

That is a general property of how virtualization platforms expose CPU features, not something specific to Google's implementation. It is also why the same instruction was issued for Rome, Milan, and Genoa customers at the original July 2025 disclosure.

FAQ

What are the three flaws?

TSA-SQ (CVE-2024-36350), TSA-L1 (CVE-2024-36357), and TSA-Fill (CVE-2026-0004). All are Transient Scheduler Attacks. The first two were disclosed in July 2025 for earlier EPYC processors, and the third is new.

What did AMD change about Zen 5?

AMD now says Zen 5 processors, which include Turin, are impacted differently from previously characterized AMD processors. The Xen Project noted that AMD had previously said Zen 5 was not vulnerable to TSA-SQ and TSA-L1, and that statement has been corrected.

Do I need to patch and restart?

Yes, both. Patch the guest OS when your vendor ships the fix. Then stop and start the VM after Google's CPU information update reaches it. Rebooting the guest OS is not enough.

Why isn't a reboot sufficient?

Because the guest learns its CPU capabilities from the hypervisor at boot, and the corrected CPU information only gets reported after the instance is stopped and started. A reboot from inside the guest does not re-read it.

Which machine types are affected?

C4D, N4D, H4D, Z4D, and G4, including bare-metal instances of C4D and Z4D.

Is this a cross-tenant risk?

Google says it has already mitigated attacks between VMs and between VMs and the host. The remaining exposure is inside a single VM, where an attacker with code on the same core may infer data from other processes or the kernel.

How severe is it?

Google rates it Medium. AMD classifies all three as local attacks with high attack complexity and low privilege requirements. Neither reports exploitation, and none is in CISA's KEV catalog.

Is the Linux kernel fixed?

A kernel commit is in the source tree. Debian has fixed CVE-2026-0004 only in unstable. Its security tracker still lists bookworm, trixie, and forky kernels as vulnerable.

What about bare metal?

Apply your vendor's fixes. AMD says both platform firmware and OS updates are needed for a full mitigation, and that performance may be affected.

What about Xen?

The Xen Project published hypervisor patches in its advisory. It says microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23.

Does Cloud Run need anything?

No. Google lists no action for Cloud Run.

How do I know when the CPU information update has reached a VM?

Google has not published a method for that. That is a real gap in the guidance, and administrators are left to restart the full affected set or build their own verification.

Source: The Hacker News