Infinity Fabric Misconfiguration: A Path to AMD SEV-SNP Compromise

Infinity Fabric Misconfiguration: A Path to AMD SEV-SNP Compromise

The promise of confidential computing, particularly with AMD’s Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), hinges on rigorous hardware-level isolation. SEV-SNP aims to protect guest virtual machines (CVMs) from a compromised hypervisor by encrypting guest memory and validating memory integrity. The threat model, however, often stops at the hypervisor, overlooking the crucial role of firmware, specifically UEFI, in configuring the underlying hardware. CVE-2025-54510, dubbed “Fabricked,” exposes a critical trust boundary violation where a malicious hypervisor can exploit misconfigurations in the Infinity Fabric, the vital interconnect fabric within AMD EPYC processors, to bypass SEV-SNP entirely. This isn’t a theoretical exploit; it’s a deterministic, software-only attack demonstrated on Zen 5 EPYC processors, allowing arbitrary read and write access to encrypted guest memory.

The Trust Boundary Erosion via UEFI

At the heart of the Fabricked vulnerability lies AMD’s reliance on UEFI firmware for critical Infinity Fabric configuration during the boot process, even for SEV-SNP enabled systems. While UEFI firmware itself is generally considered untrusted in a confidential computing context, AMD delegates the responsibility of locking down specific Infinity Fabric configuration registers to this very firmware. The attack vector begins with a compromised UEFI image. A malicious hypervisor can subvert the boot process by injecting a modified UEFI firmware. This custom firmware then intentionally omits the necessary API calls that would normally hard-code or seal specific Infinity Fabric registers, preventing dynamic modification.

This deliberate skip during initialization leaves the interconnect configurable by a malicious hypervisor after SEV-SNP has been initialized. Imagine critical security settings being left unset because a configuration script was deliberately skipped. That’s precisely what happens here. The Infinity Fabric, responsible for communication between CPU cores, memory controllers, and I/O components, becomes a pliable instrument for an attacker. This oversight fundamentally breaks the assumption that hardware configuration, once established during boot and secured by SEV-SNP’s initialization, remains immutable.

Memory Transaction Hijacking: The Data Fabric’s Deception

With the Infinity Fabric’s configuration registers left unlocked, the malicious hypervisor gains the ability to program these interconnects dynamically. The core of the exploit involves manipulating the MMIO (Memory-Mapped Input/Output) routing rules within the Data Fabric. Crucially, the vulnerability exploits a precedence issue: Data Fabric MMIO routing rules are programmed to override DRAM rules.

The Platform Security Processor (PSP), a dedicated security co-processor within AMD CPUs, performs essential security functions during the boot sequence. One of its critical tasks is initializing the Reverse Map Table (RMP). The RMP is the gatekeeper for SEV-SNP, enforcing memory access controls and ensuring that only authorized entities can access a CVM’s memory. It acts as a hardware-based access control list for encrypted memory pages.

The Fabricked attack hijacks memory transactions that the PSP intends to direct to DRAM for RMP updates. Instead of writing to the RMP in DRAM, the attacker-programmed Infinity Fabric misdirects these PSP memory transactions. These writes are silently diverted to MMIO memory regions. This misrouting is not a random error; it’s a precisely controlled redirection, enabled by the earlier UEFI-induced misconfiguration. The malicious hypervisor, by controlling the Infinity Fabric’s routing logic, can effectively intercept and redirect these critical security updates.

RMP Corruption: Nullifying the Guardian

The consequence of this memory transaction hijacking is the inability of the PSP to properly initialize the RMP during the SNP_INIT phase. Since the RMP entries are being written to the wrong memory location (MMIO instead of DRAM), the RMP remains in an insecure, default state. This default state is not one of secure isolation; it’s a state that remains under the hypervisor’s control. Effectively, the hardware guardian of CVM memory is never properly armed.

This failure to initialize the RMP means that the fundamental memory access controls that SEV-SNP relies upon are never established. The RMP, which should be enforcing strict boundaries between the hypervisor and the CVM, and between different CVMs, remains in a pliable state, effectively allowing the hypervisor to bypass its intended security checks. This leaves the CVM’s encrypted memory vulnerable to unauthorized access, negating SEV-SNP’s core promise of confidentiality and integrity. The entire security posture established by the hardware and the SEV-SNP firmware is rendered moot because its enforcement mechanism was never correctly configured.

Total Compromise: The Unraveling of Confidentiality

Once the RMP is corrupted and remains under hypervisor control, the malicious hypervisor achieves arbitrary read and write access within the victim CVM’s address space. This is the ultimate goal of confidential computing attacks: to gain complete control over the guest’s data and operations, even when encryption is in place. The attacker doesn’t need to find a bug in the CVM’s application code or exploit a kernel vulnerability within the guest. The exploit operates at a level below the CVM, directly manipulating the hardware interconnect and its security controls.

The Fabricked vulnerability is a 100% deterministic, software-only exploit. This means it can be reliably reproduced and executed without requiring physical access to the hardware or any code execution within the victim CVM. The attack chain is clear:

1. Subvert UEFI: Inject a malicious UEFI firmware that skips Infinity Fabric lockdown API calls.
2. Manipulate Infinity Fabric: Program the unlocked Infinity Fabric to misroute PSP memory transactions.
3. Hijack RMP Writes: Divert PSP writes intended for the RMP to MMIO memory.
4. Prevent RMP Initialization: The RMP is left uninitialized and under hypervisor control.
5. Achieve Arbitrary Access: The hypervisor can now read from and write to any part of the CVM’s memory space.

This entire sequence bypasses SEV-SNP’s protections, turning a supposedly secure environment into an open book for a compromised hypervisor. The public proof-of-concept, available on GitHub at fabricked-attack.github.io/fabricked-poc, uses C code to demonstrate these exact steps, underscoring the low-level nature of this attack.

The Firmware Update Burden: A Lingering Shadow

The disclosed mitigation for CVE-2025-54510 involves updates to both the SEV firmware and the Platform Initialization (PI) firmware, which is intrinsically tied to UEFI. While this addresses the immediate vulnerability, it highlights a persistent, systemic challenge in securing modern computing platforms. Firmware updates, especially for server-grade hardware used in cloud environments, are notoriously slow and complex. Orchestrating UEFI and PI firmware updates across a fleet of heterogeneous servers, often requiring reboots and downtime, is a logistical and operational hurdle. This means that even with a fix available, a significant window of vulnerability can persist across vast numbers of systems. This echoes the difficulties encountered in patching system-level vulnerabilities, as seen in responses to issues like the ‘Copy Fail’ Linux Vulnerability, where coordinated patching across diverse environments is a non-trivial task. The extended disclosure embargo, lifting on April 14, 2026, following a responsible disclosure in August 2025, further illustrates the lead time required for such fixes to be deployed.

Architectural Fragility: The Interconnect’s Tightrope

Beyond the immediate CVE, Fabricked exposes a deep architectural fragility. The core issue stems from a subtle oversight in how MMIO routing rules interact with critical DRAM write operations during security processor initialization. This interaction, specific to the Infinity Fabric’s complex chiplet architecture, demonstrates the immense difficulty in exhaustively verifying security properties across interconnected hardware components. The reliance on dynamic configuration of the interconnect, even for security-critical paths, creates an attack surface that is hard to reason about and even harder to test comprehensively. It’s a stark reminder that hardware security is not just about isolated components but about the predictable and secure interaction of all parts.

Memory Safety Precedence: Hardware Undermining Abstraction

From a compiler engineer’s perspective, this vulnerability serves as a profound cautionary tale. We dedicate significant effort to developing language features and compiler techniques that enforce memory safety – Rust’s ownership system, static analysis tools, and careful use of C++ abstractions. These are all designed to prevent bugs that lead to buffer overflows, use-after-free errors, and other memory corruption issues. However, the Fabricked exploit demonstrates that all these higher-level assurances become irrelevant if the fundamental hardware mechanism for enforcing memory access controls, the RMP, can be subverted at boot time. A perfectly memory-safe CVM running on hardware with a compromised RMP is no more secure than a C program with critical memory bugs. The hardware-level memory safety guarantees provided by SEV-SNP, when they fail, render all software-level efforts moot.

Bonus Perspective: The “Cross-Component Attack” Paradigm

Fabricked is not an isolated incident; it’s presented as an instance of a broader class of “Cross-Component Attacks (XCA).” This classification implies that vulnerabilities arise from the manipulation of interconnects between different processor components or chiplets. The fact that the vulnerability impacts the Infinity Fabric, a core component responsible for inter-chiplet communication in modern AMD processors, suggests that other vulnerabilities might exist by similarly subverting these high-speed interconnects. Furthermore, the similarity to the “RMPocalypse” vulnerability (CVE-2025-0033), which similarly targeted RMP initialization via a race condition allowing an 8-byte write, underscores the critical yet fragile role of the RMP. These attacks collectively highlight the intricate and vulnerable nature of the RMP, a component that stands as a single point of failure for SEV-SNP’s entire security model.

Opinionated Verdict

While AMD’s SEV-SNP represents a significant step towards hardware-rooted confidential computing, CVE-2025-54510 proves that the attack surface extends into the firmware and interconnect layers. The Fabricked vulnerability is a clear demonstration of how a single, albeit complex, misconfiguration in the Infinity Fabric, stemming from UEFI’s role, can completely nullify sophisticated hardware-based memory protection. For cloud architects and security engineers, this mandates a deeper scrutiny of firmware update strategies and a recognition that hardware security is an ongoing, multi-layered battle. Relying solely on higher-level abstractions or even SEV-SNP’s promise without considering the integrity of the boot process and the underlying interconnect fabric is a perilous gamble. The onus is now on system designers and operators to ensure not just software, but the very initialization vectors of their hardware, are beyond reproach.