Every protection that walls off memory on a modern x86 machine, the SMM lock, the PSP carveout, the microcode patch RAM, works by deciding which physical addresses a core is allowed to touch. Christopher Domas just published tooling that ignores that question entirely. His release went up on GitHub this afternoon and hit the Hacker News front page within the hour, on 13 August 2026. It flips one bit in an AMD memory controller register so that a physical address the operating system is perfectly entitled to use lands on the same DRAM capacitors that hold the protected data. Nothing is bypassed at the permission layer, because the attack happens underneath it.
The work is the tool drop for his Black Hat USA 2026 briefing, Spaghettifying DRAM: Breaking Everything with Memory Collision Exploitation, presented at Mandalay Bay during the 5 and 6 August briefings. The repository, named skitter-creek-bath-salts, carries the working code: dram_read, dram_dump, dram_poke, plus two Python helpers that do the maths.
RelatedCISA Flags TeamCity RCE: An XStream Allowlist Left Open
What the bit flip actually does
A physical address is not a location. It is an input to another translation. The memory controller takes those bits and scatters them across a DRAM chip's real coordinates: channel, rank, bank group, bank, row, column. That scatter exists for performance, not security, and it is configurable, because board vendors need to tune interleaving for different DIMM populations.
Domas's core observation is that the scatter is a linear map over GF(2). Every DRAM coordinate bit is an XOR of some subset of physical address bits. Change the configuration and you change the matrix. On the AMD parts he targets, one write does it:
xor dword [0xf80c2094], 1<<22
That toggles bank swizzle mode in the DRAM controller. The address space is now, in his word, spaghettified: the same address reaches different capacitors than it did a microsecond earlier. To find out which capacitors, the toolchain writes sentinel values, reads back where they surface in both the coherent and the scrambled view, feeds those pairs to the z3 SMT solver, and recovers the transformation matrices. unspaghettify.py saves the resulting alias map. After that, reaching a protected address is arithmetic: compute the alias, flip the bit, read, flip it back.
Why do the protections not see it coming?
Because they are not looking at that layer. TSEG, the PSP carveout and the IOMMU are range checks: they compare a physical address against a base and a limit and refuse the ones inside. They fire correctly every single time during this attack. The attacker never asks for a forbidden address, so nothing ever gets denied.
This is what separates the technique from Rowhammer, which is the closest well known relative. Rowhammer is a fault injection attack: hammer aggressor rows hard enough and a neighbouring victim row loses a bit, and you take whatever corruption you can get. Spaghettifying is not corrupting anything. It is reading and writing the exact bytes you asked for, through a legitimate configuration state the platform ships with.
The operational sequence in the repo is deliberately careful about this. Prime the TLBs and warm the caches with the target addresses first, disable interrupts and park the application processors, flip the bit, do the access, flip the bit back. Memory is coherent again before anything else on the machine notices it moved. Domas reports no platform corruption.
What sits in the memory it reaches
The four regions the toolchain demonstrates are not incidental targets. They are the places the platform puts things specifically because software is not supposed to see them.
| Region | What it holds | Why it was considered safe |
|---|---|---|
| PSP carveout | Firmware TPM state, RSA routines running on the on-die ARM core | Fenced off from the x86 cores entirely, not mapped in the OS view |
| SMM | SMI entry vectors and handlers at SMBASE+0x8000, ring -2 code | Locked by TSEG once firmware sets the SMM lock bit at boot |
| C6 save area | Per core architectural context stashed while a core is power gated, about 16 KiB each | Written and read only by hardware during idle transitions |
| Microcode patch RAM | The loaded microcode patch, backed up so it can be restored on C6 wake | Patch RAM is volatile and considered unreadable from software |
That last one deserves a pause. CPU microcode is one of the few genuinely opaque blobs left on a modern machine: signed, encrypted in distribution, loaded into a write only patch RAM. But something has to restore it when a core wakes from a deep idle state, and the restore copy sits in DRAM like everything else. Domas recovers it from there.
Does this mean your Ryzen is exploitable today?
No, and this is the part worth getting right before it gets repeated badly.
The published work is developed and tested on AMD Family 16h, the Jaguar and Puma generation from roughly 2013 and 2014. Domas is explicit about why: 16h is the last AMD family whose public datasheets document the DRAM controller's translation registers. Family 17h onward, meaning every Zen part in a desktop, laptop or server you would buy today, does not publish those register definitions. That is a documentation gap, not a fix, and Domas says so, but it does mean nobody has publicly shown this working on Zen.
RelatedA one-line firmware check cost Coldcard users 1,082 BTC
Two more constraints matter for how you rate the risk. The attack needs ring 0, since it writes memory controller MMIO and quiesces the other cores. An attacker who already has kernel code execution has a lot of options, so this is not a remote break of anything. What it is, precisely, is a privilege escalation from ring 0 into the things ring 0 was specifically never meant to reach: firmware secrets, the fTPM's key material, and ring -2. On a machine where the whole security model assumes the hypervisor or the PSP outranks the kernel, that distinction is the entire ballgame.
And the transform class is not AMD specific. Address scrambling in some form is present across Intel, ARM and RISC-V memory controllers, because it is a performance feature everyone wants. Whether their configuration paths are reachable and unlocked is an open question that this release makes considerably more interesting.
- 2017Sandsifter Fuzzing the x86 instruction set turns up undocumented instructions across vendors
- 2018Rosenbridge A hidden RISC core inside a VIA x86 chip, reachable from ring 3, grants ring 0
- 5-6 Aug 2026Black Hat USA briefing Spaghettifying DRAM presented in the platform security and hardware tracks
- 13 Aug 2026Tooling published skitter-creek-bath-salts lands on GitHub with read, dump and poke primitives
- NextFamily 17h and beyond Undocumented does not mean locked; expect reverse engineering attempts on Zen controllers
Why documentation is not a mitigation
The reason this works on 16h is blunt: the translation registers have no lock bits. There is no equivalent of the SMM lock, no one way latch that firmware closes at boot and the OS cannot reopen. The registers stay writable for the life of the system because interleaving was designed as a tuning knob, and nobody modelled a tuning knob as a security boundary.
AMD's later families responded by removing the register descriptions from public datasheets. That raises the cost of finding the bits, which is real, but it is security through obscurity in the textbook sense. The bits still exist, the controller still accepts writes to them, and Domas's own solver approach is precisely the sort of thing that turns undocumented into documented. His framing is the memorable part: everything so carefully walled off is still sitting in the same physical capacitors.
- A lock bit, or an admission there isn't one. The clean fix is a one way latch on the DRAM controller's translation configuration, set by firmware before the OS runs. Watch for it in AGESA release notes rather than in a security advisory.
- Zen replication. The first credible demonstration on Family 17h or later is the moment this stops being an archaeology exercise. The register hunt is now a well defined problem with a published solver.
- Intel, ARM and RISC-V follow ups. The linear algebra generalises. The interesting question is which vendors left the configuration path writable after boot.
- fTPM assumptions. Anything whose threat model treats the firmware TPM as opaque to a compromised kernel, including some disk encryption and attestation flows, needs a re-read on affected silicon.
Our take
The reflex response to hardware research like this is to ask for a CVE number and a patch, and there isn't one, which makes it easy to file the whole thing under interesting but academic. That would be the wrong read. What Domas has published is a new place to stand, not a single bug. For twenty years the industry has hardened the path from a virtual address to a physical one, and it has got genuinely good at it. This is a demonstration that the path keeps going after the checks stop, and that the last stretch of it was left configurable because it was never treated as part of the security story at all.
The Family 16h limitation is a real limitation and should be stated every time this gets covered. But the useful way to read a technique paper is by what it makes cheap for the next person, and this one hands out a solver, a working alias map generator, and three primitives. The register hunt on newer silicon is now the only thing standing between this and a much less comfortable headline.
- Codexoreaxeaxeax/skitter-creek-bath-salts , the released toolchain, alias solver and technical writeup
- ConferenceBlack Hat USA 2026 briefings schedule , Spaghettifying DRAM, platform security and hardware tracks
- ReferenceAMD BIOS and Kernel Developer's Guide archive , Family 16h documents the DRAM controller translation registers; later families do not
- DiscussionHacker News thread , submitted 14:17 UTC on 13 August 2026
- WatchlistGenZTech CVE Watchlist , our running record of what is being exploited and what needs action
Original analysis by GenZTech, based on the skitter-creek-bath-salts repository and its accompanying writeup by Christopher Domas, and on the Black Hat USA 2026 briefings schedule. Hacker News submission time read from the public API at 15:10 UTC on 13 August 2026.