AMD Discloses Elevation of Privilege Vulnerability in Zen 2 Micro-Op Cache — Microcode and Firmware Updates Required

AMD has disclosed a vulnerability in the micro-op cache present in its Zen 2 microarchitecture that enables an unprivileged process to exploit speculative execution behaviour and gain visibility into privileged memory content. The disclosure follows a pattern established by Spectre and Meltdown class vulnerabilities: hardware-level optimisations designed for performance become exploitable channels for information leakage when microarchitectural state persists inappropriately across privilege boundaries.

Technical Background

The micro-op cache — also known as the decoded instruction cache — is a hardware optimisation that stores pre-decoded CPU instructions to avoid re-decoding on repeated execution paths. In Zen 2, the μop cache does not fully flush entries across privilege level transitions under specific conditions. A carefully crafted user-space process can prime the cache with entries that persist into a kernel-context execution window and observe timing side-effects that reveal kernel memory content.

Exploitation requires local code execution — this is not a remotely triggerable vulnerability. An attacker with an existing low-privilege foothold (through phishing, malicious application, or initial exploitation of another flaw) can use this to read kernel memory, potentially recovering credentials, cryptographic keys, or sensitive data that the kernel processes on behalf of other users or services.

In virtualised environments — particularly cloud instances and on-premises hypervisors running Zen 2-based EPYC Rome processors — the cross-privilege-boundary access creates the possibility of cross-tenant or guest-to-hypervisor information leakage, depending on hypervisor isolation configurations.

Affected Hardware

All processors based on the AMD Zen 2 microarchitecture are affected:

Zen 3 (Ryzen 5000 / EPYC Milan), Zen 4 (Ryzen 7000 / EPYC Genoa), and Zen 5 are not affected.

Remediation Path

Full remediation requires a microcode update from AMD distributed via platform firmware:

• Dell PowerEdge servers (EPYC Rome): Updated iDRAC firmware and BIOS available via Dell support. Centralised deployment via Dell OpenManage or iDRAC Lifecycle Controller is supported. This is the priority for enterprise estates.
• HPE ProLiant servers: Firmware updates via HPE Service Pack for ProLiant (SPP).
• Consumer and enterprise desktop/laptop: Updated AGESA firmware distributed through motherboard and OEM BIOS updates. Check the device manufacturer’s support site.
• Linux interim mitigation: Kernel patches addressing speculative execution mitigation are distributed through standard distribution update channels (RHEL, Ubuntu, SLES). These reduce risk pending firmware availability.
• Windows: Microsoft Windows updates include OS-level mitigations for this class of vulnerability.

Why It Matters

EPYC Rome remains deployed across a substantial portion of enterprise data centres from the 2020–2022 hardware refresh cycle. For organisations running multi-tenant workloads — virtualised environments, shared Kubernetes clusters, and managed hosting — the risk of cross-privilege data leakage is elevated. A container or VM on a Zen 2 hypervisor could potentially access memory belonging to the hypervisor or adjacent workloads.

Unlike software vulnerabilities patched by deploying an update to a running system, CPU microarchitecture vulnerabilities require firmware updates that typically need a system reboot and planned maintenance windows. In environments with strict uptime requirements, this creates a gap period that needs to be managed through compensating controls.

Recommended Actions

• Inventory Zen 2 systems: Run a hardware audit to identify AMD EPYC Rome, Ryzen 3000/4000, and Ryzen PRO 4000 systems. Dell PowerEdge and HPE ProLiant servers from the 2019–2022 generations are the most likely enterprise exposure.
• Server firmware first: Apply Dell or HPE firmware updates to EPYC Rome servers. Use Dell iDRAC’s firmware management or HPE iLO to deploy updates, scheduling reboots during planned maintenance windows.
• Apply OS-level mitigations immediately: For Linux systems, apply kernel updates from your distribution vendor. These are available without a reboot in some cases via live patch services (RHEL Live Patching, Ubuntu Livepatch).
• Multi-tenant isolation review: For shared infrastructure — cloud-hosted workloads, virtualised environments running mixed tenancy — evaluate whether sensitive workloads should be migrated to non-affected hardware pending firmware deployment.