Exploit in DRAM controller registers breaks memory isolation in AMD CPUs

Security researcher Christopher Domas presented skitter-creek-bath-salts, an open source hardware security project that attacks the lowest layer of the physical memory hierarchy to bypass CPU privilege boundaries. According to InfoQ, the technique manipulates memory controller translation registers to dynamically change, at the hardware logic level, the mapping of physical addresses to actual DRAM locations. The result is that unprivileged software can access platform-isolated memory regions without triggering architectural checks or generating fault exceptions.

The assumption modern architecture makes

Modern processors start from a premise: physical addresses map deterministically to specific silicon locations. Standard security barriers, including the hypervisor's Extended Page Tables (EPT), the System Management Mode's TSEG range limits, and the Platform Security Processor's (PSP) private carveouts, operate at the core and system interconnect fabric layer, meaning before memory traffic reaches the controller.

Domas's discovery is that the memory controller's translation registers sit below these access control barriers. By altering configuration bits, such as BankSwizzleMode, one fundamentally changes how the controller calculates the DRAM's bank, row, and column coordinates. Because upstream security filters only validate the untranslated physical address, these bit flips cause ordinary memory accesses to silently fall within protected hardware enclaves.

How the exploit extracts data

To read scrambled memory without crashing the host operating system, the exploit uses a multi-stage software pipeline. A custom Linux kernel module powers down unused CPU cores at boot, flushes system caches, pre-warms the TLBs (translation lookaside buffers), and disables interrupts to ensure memory stability while the mappings are "rewired."

Next, automated probing scripts use a coupon-collector heuristic combined with targeted userspace reads to catalog address bit collisions. The toolchain models the physical address permutation with Galois Field arithmetic and employs an SMT solver to derive the exact bit-by-bit mapping. Once the map is solved, the exploit runs bursts of reads and writes against previously untouchable enclaves, including:

• SMM RAM (System Management Mode)
• PSP firmware tables
• Processor CC6 sleep-state save areas
• Microcode patch buffers

The architectural blind spot

The finding exposes a central distinction between CPU privilege and platform privilege. Upstream security checks cannot guarantee integrity if the downstream memory controller logic allows dynamic address swizzling. In the AMD 14h, 15h, and 16h families, Ring 0 software can manipulate these settings, and this level of access is, according to the analysis, inherently insufficient: it treats the kernel as inherently trustworthy.

The technical recommendation emerging from the work is straightforward: the memory controller's translation registers need to be strictly locked during boot. The reality of adversarial kernels requires that critical platform settings be managed by boundaries above CPU privilege, not within it.

Practical limitations

Hardware security and reverse engineering communities on Reddit (such as r/asm and r/blueteamsec) and podcasts like SANS ISC Stormcast reacted with interest. The discussions highlighted both the architectural implication (platform barriers live above the memory controller and therefore ignore the scrambling of raw physical coordinates) and the practical limits of the attack.

Two points contain the immediate risk: the exploit requires Ring 0 privilege, meaning the attacker must have already compromised the kernel; and it targets registers accessible primarily on older AMD processors from the 15h and 16h families. This is not a remote attack, nor one executable from scratch by unprivileged code.

What changes for those operating infrastructure in Brazil

The concrete risk scenario is trusted computing and bare-metal cloud. Providers that offer dedicated servers or bare-metal instances with AMD hardware from these generations, and environments that rely on confidential computing to isolate sensitive workloads, are exactly the cases where the boundary between "tenant" and "platform" is what underpins the security guarantee.

For Brazilian teams running their own infrastructure or contracting bare-metal services, the practical takeaway is about inventory: identifying which machines use AMD CPUs from the 14h, 15h, and 16h families and assessing whether they are in contexts where a compromised kernel is a realistic part of the threat model. In multi-tenant environments on older bare-metal hardware, the guarantee that SMM RAM, PSP firmware, and microcode buffers are actually isolated is no longer automatic.

Long-term mitigation points remain open: whether and how AMD will address locking these registers in firmware for hardware already in the field, and to what extent newer processor generations already close this window. The skitter-creek-bath-salts project is open source, which means the technique is available for study, and also for reproduction, by any security team.