AMD Family 15h and 16h Memory Aliasing: What Skitter Creek Bath Salts Means for Secrets

AMD has confirmed a memory-aliasing issue affecting certain Family 15h and 16h processors, while researcher Christopher Domas has published a Family 16h proof of concept that can reach DRAM regions intended to be hidden even from the operating system kernel. The research, named Skitter Creek Bath Salts, demonstrates access to memory used by the Platform Security Processor, System Management Mode, CPU sleep state and microcode patch storage.

The dramatic “one instruction” description needs context. This is not a drive-by web attack or an unprivileged route into a machine. AMD says the attacker must already have root or administrator privileges, and the public tooling requires kernel-level control. The important lesson is what can happen after that level of compromise: boundaries below the operating system may no longer protect secrets processed on the affected host.

What AMD confirms

AMD published security bulletin AMD-SB-7068, “Memory Aliasing Vulnerability,” on August 6, 2026. The company says an external researcher reported that memory-controller configuration registers responsible for system-memory address translation may not be lockable on certain Family 15h and 16h processors.

AMD identifies Family 15h and 16h processors as affected, but says those products have reached end of security support and no longer receive security updates. The bulletin does not list a CVE or provide a software or firmware patch. AMD also emphasizes that the described attack requires existing root or administrator privileges, which limits its practical impact as an initial compromise method.

What the public proof of concept actually demonstrates

Domas's repository explains that the attack changes a low-level DRAM address translation setting. Security controls above the memory controller protect particular physical-address ranges. If privileged code temporarily changes how those addresses map to the underlying DRAM, it can create an alternate path—or alias—to data behind those controls.

The researcher demonstrates read and write access to protected regions associated with the AMD Platform Security Processor, System Management Mode, C6 sleep-state data and microcode patch storage. Those demonstrations show why a memory-controller boundary matters: code that already controls the kernel may be able to cross into areas designed to remain inaccessible even at ring 0.

We are deliberately not reproducing the configuration write, memory addresses or operational commands. The public repository contains working root-level tooling, and defenders do not need exploit instructions to assess exposure or respond safely.

Family 15h and Family 16h are not equally demonstrated

AMD's bulletin covers both Family 15h and 16h. Tom's Hardware also reports both families as affected. However, the researcher's README and platform-check code say the published implementation was developed and tested on AMD Family 16h. The tool marks other AMD families as untested because the relevant northbridge configuration layout is family-specific.

The careful conclusion is therefore two-part: the vendor confirms a potential issue on certain 15h and 16h processors, while the public proof of concept directly demonstrates the technique on Family 16h. The repository does not establish that the same code works unchanged on Family 15h, modern Ryzen or EPYC platforms, Intel processors, or other architectures.

Why this matters even when the attacker already has root

Root access is already a serious incident, but defenders still rely on boundaries below the operating system. Firmware services, trusted execution components, TPM functions and protected memory can hold code or data that organizations expect a compromised kernel not to read or modify. A path around those boundaries can make persistence, forensic confidence and recovery more difficult.

The practical risk depends on the machine's role. An unsupported desktop with no sensitive workload is different from a legacy appliance, signing station, build host or recovery workstation that processes long-lived credentials. The age of the processors reduces their population, but unsupported hardware can remain in embedded and operational environments long after ordinary office refresh cycles.

A defensive checklist for legacy AMD hosts

Inventory by CPU family, not marketing name alone. Identify Family 15h and 16h systems and record which ones process credentials, signing keys, recovery material or privileged sessions.
Prioritize retirement for sensitive roles. AMD says the affected products are out of security support. Move high-value secret handling to supported hardware instead of waiting for an update that the bulletin does not offer.
Treat root compromise as a boundary failure. Do not assume firmware-adjacent or protected-memory material remained confidential merely because ordinary file-system evidence is clean.
Rebuild on trusted hardware. Recover from known-good media on a supported platform. Reinstalling the operating system on the same suspect host may not provide enough assurance for a high-impact incident.
Rotate secrets from a clean endpoint. Replace credentials, tokens and recovery values that were decrypted or used on the compromised system. Perform the rotation from a separate, trusted device.
Reduce driver and kernel attack paths. Restrict local administration, remove unnecessary drivers, enforce code-signing controls where available and monitor attempts to load new kernel components.
Preserve evidence before decommissioning. Coordinate with incident responders so a hardware replacement does not erase the only useful timeline or memory evidence.

What this changes about secret sharing

A secure transfer mechanism can reduce how many permanent plaintext copies a secret leaves in chat, email and ticket systems. It cannot protect a value after that value is decrypted on an endpoint controlled at the kernel or hardware boundary. The recipient device is part of the trust decision.

For sensitive handoffs, verify the recipient and the endpoint separately. Prefer a scoped, temporary credential; deliver it to a supported and trusted device; keep its lifetime short; and rotate it after use or after any suspected privileged compromise. Do not use an unsupported legacy host as the machine from which you create replacement credentials or restore a recovery secret.

Where Secretus fits—and where it does not

Secretus can help an authorized sender avoid placing a password, recovery code or token directly into a persistent communication transcript. Standard Mode supports a short-lived, one-time handoff, while Team Split can support a planned multi-person reconstruction workflow.

Secretus is not an endpoint-security, firmware-integrity or hardware-attestation tool. It cannot make an affected or root-compromised computer trustworthy, and it cannot stop malicious code from capturing a secret when the recipient reveals it. Use a clean, supported endpoint and rotate exposed values; do not treat one-time transport as protection from post-decryption compromise.

What remains unknown

The public sources reviewed for this article do not report exploitation in the wild. AMD's bulletin does not assign a CVE, enumerate every affected product model or offer a patch. The public project demonstrates Family 16h, while Family 15h applicability is covered by AMD's assessed report rather than by the same tested implementation. Claims that this exact technique compromises newer CPU families or unrelated architectures are not established by the published proof of concept.