One bit-flip unlocks protected DRAM on AMD Family 16h chips

Key facts

• The proof-of-concept, published on GitHub as skitter-creek-bath-salts, flips bit 22 of an AMD DCT memory-controller register with one instruction, xor dword [0xf80c2094], 0x00400000, to rewire DRAM address translations and expose four categories of protected regions: the Platform Security Processor, System Management Mode, C6 DRAM, and CPU microcode.
• Every check above the memory controller, privilege levels, permission bits, cache and coherence logic, operates on physical addresses; none of it inspects the DRAM coordinates the memory controller produces at the final translation stage, so rewiring those coordinates goes unnoticed.
• The flipped bit is the DCT's bank-swizzle-mode bit, one of dozens of similar remap-controlling bits in that register; the documented method disables the platform's other CPU cores, scrambles the mapping just long enough to read the target data, then reverts it, leaving the platform in its normal state.
• Because the DRAM controller's address transform is linear over GF(2), built entirely from XOR operations, the project reconstructs exactly where a physical address lands after scrambling using ordinary linear algebra, working around AMD datasheets it says are underspecified on the resulting transform.
• The technique was developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers and show they cannot be locked; AMD's datasheets for Family 17h and later omit that documentation, and the project does not demonstrate the same attack against those newer chips.

Why it matters

Modern CPUs stack many independent protections, privilege levels, execute and write permissions, protection keys, and carve out regions of DRAM meant to stay invisible even to the kernel. The project names four such regions: the space used by AMD's Platform Security Processor, by System Management Mode, by CPU microcode, and what it calls C6 DRAM. All of those protections reason about physical addresses. skitter-creek-bath-salts shows that the memory controller itself, the very last stage before a physical address becomes a bank, row, and column on the DIMM, can be reprogrammed with a single bit-flip, and that nothing above it ever checks whether that final translation has changed. Once the mapping is scrambled, an ordinary address starts pointing at data that every protection above the memory controller assumed was unreachable.

Who it affects

The technique targets AMD Family 16h CPUs specifically. The project describes that family as the last one whose public datasheets document the DRAM controller's translation registers, and says those datasheets show the registers cannot be locked. AMD's datasheets for Family 17h and later leave that documentation out, and the project does not demonstrate the same register-level attack against those newer chips. It argues that the broader address-translation path, down through the TLB, the page walker, the caches, and finally the memory controller, stays structurally similar across CPU generations and architectures, and says the underlying transforms extend even to ARM and RISC-V chips. But it is explicit that skitter-creek-bath-salts only shows how to begin: the working proof-of-concept, and the exact register it pokes, are specific to AMD Family 16h.

How to use it

The project publishes the raw instruction sequence in assembly and says the address scrambling can be made to work from C, so the technique can be reproduced directly rather than taken on faith. The one instruction that does the actual work is xor dword [0xf80c2094], 0x00400000, which flips bit 22, the bank-swizzle-mode bit, one of dozens of similar remap-controlling bits at that MMIO address. Reproducing it safely needs the full documented sequence around that single flip: disabling the other CPU cores, priming the TLB and cache, disabling interrupts, flushing the target cache line, relying on the CPU having already prefetched what runs next, and serializing memory accesses before and after the flip, then reverting it and resuming normal operation. The project frames the register-level detail, which exact bit, which exact address, as specific to AMD Family 16h; applying the same idea to other AMD generations or other vendors' chips means first finding the equivalent registers on that platform, which this project does not do.

How solid is it

Every claim here traces to the project's own README and diagrams; no outside researcher, vendor statement, or advisory is cited anywhere, and the text names no author, date, or organization behind the work. The central technical claim, that the DRAM controller's address transform is linear over GF(2) and therefore solvable with ordinary linear algebra, is backed by the project's own worked matrix example rather than an independent audit. The write-up is precise about mechanism: the exact register address, the exact instruction, and the exact bit position are all given. What it does not report is a success rate, how long the scrambled window has to last, or how many attempts the technique takes, so how it performs outside the project's own test setup is not established here.

Risks and caveats

The text does not say whether this behavior has been reported to AMD, whether AMD has responded, or whether any CVE has been assigned, so the disclosure status is unknown from this source. No specific CPU model or motherboard is named beyond the Family 16h label. This is a proof-of-concept, not a claim of real-world exploitation: the project presents the code as something that can be made to work from C, not as an attack observed in the wild. Running it also means briefly disabling interrupts and other CPU cores while scrambling all of system memory on a live machine, a state the project's own account frames as one it has to work to survive without crashing.

“That's the exploit. All of it.”

— the skitter-creek-bath-salts README