AMD Turin: three CPU flaws force patching and VM reboots

Google Cloud has issued an advisory this week affecting virtual machines deployed on AMD Turin processors. The problem is not in the cloud itself, but in the silicon: three side-channel flaws in the CPU allow an attacker with code running on the same processor core to infer information from other processes or even from the kernel within the same virtual machine.

It is worth understanding the scope clearly before raising the alarm. Google has already applied mitigations to its infrastructure to block attacks between virtual machines and between a VM and the host. In other words, isolation between platform customers is covered. The remaining gap is within each VM: if an attacker manages to execute code in a process of the guest system, they could attempt to read data from other processes sharing the same physical core.

What an IT team needs to do

The practical part of the advisory is what has the greatest impact on day-to-day operations: applying a patch to the guest operating system is not enough. According to Google, protection requires updating the VM's operating system and also stopping and restarting the instance. A simple reboot within the system is not sufficient; the full cycle from the platform console is needed for the mitigation to be applied effectively.

That detail is what usually breaks schedules. In a small business with two or three virtual servers, it is a manageable maintenance window. In an environment with dozens of instances, clusters, or stateful services, the work must be organized:

• Inventory first: identify which VMs run on AMD Turin and which are critical due to workload or Internet exposure.
• Prioritize exposure: instances running third-party code, customer containers, or multi-user applications come first, because the attack scenario requires local execution.
• Plan the stop/start: check dependencies, queues, load balancers, and persistent storage before shutting down. A poorly coordinated stop generates more incidents than the flaw itself.
• Verify afterwards: confirm that the guest system was updated and that the instance started with the mitigation active.

Beyond the patch: the threat model

Side-channel flaws in CPUs are not new. The Spectre and Meltdown family of vulnerabilities has been reminding us for years that software isolation depends on hardware behavior. What is relevant here is that the exploitation scenario requires the attacker to already have the ability to execute code within the VM. It is not a direct remote attack, but one more piece of a chain: first an application is compromised, then an attempt is made to escalate or read secrets from neighboring processes.

That is why the advisory fits with the lesson we repeat in other recent incidents, such as the N-central exploits that bypassed the patch or the case of Apache HTTP/2 with unauthenticated remote execution: the window between publication of the advisory and exploitation is shrinking, and patching discipline makes the difference. In this case, moreover, patching has an extra condition —the shutdown and startup cycle— that many teams overlook.

Recommendations for small businesses and small teams

There is no need to mount a crisis operation, but the advisory should be handled methodically. These are the actions we recommend at ForgeNEX:

1. Review the Google Cloud advisory and confirm which instances use AMD Turin processors. If there are none, the impact is nil and it is enough to document it.
2. If there are, open a realistic maintenance window, with communication to affected users and a rollback plan in case startup fails.
3. Take the opportunity to review segmentation: which processes share a core? Are there workloads from different customers on the same VM? Separating by criticality reduces the potential damage of any side channel.
4. Strengthen detection of anomalous execution within VMs: an attacker who is already inside is the prerequisite for this type of flaw, so process monitoring and secrets management remain the first line.
5. Maintain an up-to-date inventory of underlying hardware and guest systems. Without visibility, this type of advisory becomes a lottery.

The conclusion is simple: isolation between Google Cloud customers is mitigated, but isolation within each virtual machine depends on the customer applying the patch and completing the shutdown and startup cycle. It is a reminder that cloud security is a shared responsibility, and the part that falls to the customer cannot be delegated.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.