Security 14.08.2026, 01:22 Aktualisiert: 14.08.2026, 02:28

Skitter Creek Bath Salts: DRAM-Scrambling unterhalb von Ring 0

Der PoC manipuliert den DRAM-Controller alter AMD-CPUs. Wir erklären den Angriff, seine Grenzen und was Betreiber daraus mitnehmen sollten.

Von Moritz Mantel · Veröffentlicht: 14.08.2026, 01:22 · Aktualisiert: 14.08.2026, 02:28

Stand: 14.08.2026, 02:28 Uhr CEST. Seit der Veröffentlichung kam ein zweiter Commit hinzu, der ausschließlich den README-Text überarbeitet. Der PoC-Code ist unverändert. Eine CVE, ein öffentliches AMD-Advisory oder eine unabhängige Reproduktion haben wir weiterhin nicht gefunden. Neu ergänzt haben wir die Zuordnung von Family 16h zu konkreten Prozessorreihen. Das genaue Testsystem nennt der Autor weiterhin nicht.

Kurzfassung

Was veröffentlicht wurde: Christopher Domas hat mit Skitter Creek Bath Salts einen Linux-PoC samt Kernelmodul, Analysewerkzeugen und Beispieldaten veröffentlicht. Das Projekt verändert die Adressübersetzung im DRAM-Controller.
Was daran neu ist: Der Angriff geht unter die Schutzlogik, die mit physischen Adressen arbeitet. Eine normalerweise erlaubte Adresse kann nach einer Änderung des DRAM-Mappings dieselbe Speicherzelle treffen wie ein gesperrter Bereich.
Was der PoC zeigt: Der Autor demonstriert Lesezugriffe auf privaten Speicher des AMD Platform Security Processor, SMRAM, C6-Speicherbereiche und eine im C6-Abbild liegende Microcode-Kopie. Das Tooling enthält auch Schreibfunktionen.
Welche Rechte nötig sind: Der veröffentlichte Weg läuft als Root und lädt ein eigenes Kernelmodul. Das ist keine Remote-Lücke und keine normale User-to-Root-Eskalation.
Welche Hardware belegt ist: AMD Family 16h. Neuere Ryzen- und EPYC-Generationen, Intel, ARM und RISC-V sind durch diese Veröffentlichung nicht automatisch betroffen.
Warum Root trotzdem nicht das Ende der Diskussion ist: PSP, fTPM und SMM sollen gerade dann noch eine Grenze bilden, wenn das Betriebssystem privilegierten Code ausführt. Der PoC greift diese tiefere Vertrauensgrenze an.
Was Betreiber jetzt tun sollten: Den Code nicht auf produktiver Hardware ausprobieren. Alte Family-16h-Systeme mit hohem Schutzbedarf inventarisieren, Kernelmodul-Laden einschränken und auf eine Reaktion von AMD sowie unabhängige Reproduktionen achten.

Skitter Creek Bath Salts rekonstruiert die veränderte DRAM-Adressabbildung

Originalanimation aus dem Repository von Christopher Domas, veröffentlicht unter MIT-Lizenz. Links entsteht die gelöste Adressmatrix, rechts wird sichtbar, wie dieselben Daten unter einem anderen Mapping neu angeordnet erscheinen.

Worum geht es überhaupt?

Wenn ein Programm auf *p zugreift, landet dieser Zugriff nicht direkt an einer eindeutig beschrifteten Speicherzelle. Zuerst übersetzt die MMU eine virtuelle Adresse in eine physische Adresse. Bei virtuellen Maschinen oder Geräten können weitere Übersetzungen durch EPT/NPT und IOMMU dazukommen. Danach folgen Caches, Interconnect und schließlich der Speichercontroller.

Erst dort wird aus der physischen Adresse ein Satz konkreter DRAM-Koordinaten: Kanal, Rank, Bank, Zeile und Spalte. Diese Zuordnung ist kein simples Durchreichen der Adressbits. Speichercontroller verwenden Interleaving, XOR-Verknüpfungen und sogenannte Swizzles, um Zugriffe auf Kanäle und Bänke zu verteilen.

Die Forschung zu DRAMA hat schon 2016 gezeigt, dass sich solche oft undokumentierten Abbildungen aus dem Verhalten eines Systems rekonstruieren lassen. Auch PIkit manipulierte Adresszuordnungen im Prozessor-Interconnect, um eigentlich getrennte Speicherbereiche zu erreichen. Skitter Creek Bath Salts setzt an einem ähnlichen Grundproblem an, geht auf der untersuchten AMD-Plattform aber direkt an die letzte Übersetzungsstufe vor den DRAM-Chips.

Vereinfacht sieht der Weg so aus:

virtuelle Adresse
        ↓ MMU / Seitentabellen
physische Adresse
        ↓ Schutzbereiche, Caches, Interconnect
Speichercontroller
        ↓ Interleaving, Bank-Swizzle, Rank-Auswahl
DRAM-Koordinate: Kanal / Rank / Bank / Zeile / Spalte

Der entscheidende Gedanke lautet: Viele Schutzmechanismen prüfen die physische Adresse. Die Daten liegen aber am Ende in einer DRAM-Zelle, deren Auswahl noch von einer weiteren Abbildung abhängt.

Warum `&x` plötzlich nicht mehr dieselben Daten liefert

Im normalen Betrieb ist die Kette stabil. Liest der Kernel zweimal dieselbe physische Adresse, erwartet er zweimal dieselben Daten. Der Speichercontroller benutzt bei beiden Zugriffen dieselbe Konfiguration.

Der PoC ändert auf AMD Family 16h unter anderem das Bit BankSwizzleMode im Register D18F2x94. Dadurch interpretiert der Controller Adressbits anders. Die CPU reicht weiterhin dieselbe physische Adresse nach unten, doch diese Adresse landet nun an einer anderen DRAM-Koordinate.

Der PoC liest dieselbe Adresse vor, während und nach der Änderung des DRAM-Mappings

Die Originalanimation zeigt das Gedankenexperiment hinter &x != &x: Adresse und Seitentabellen bleiben gleich, der Speichercontroller liefert während der geänderten Konfiguration jedoch Daten aus einer anderen DRAM-Zelle.

Das Umschalten ist der einfache Teil. Gefährlich ist der Moment dazwischen. Sobald das Mapping verändert ist, könnte jeder Cache-Miss, Interrupt, Hardware-Prefetch oder Zugriff eines zweiten CPU-Kerns an der falschen Stelle im RAM landen. Ein gewöhnlicher Kernel würde sich damit sehr schnell selbst zerlegen.

Das Kernelmodul versucht deshalb, diesen Zustand extrem kurz zu halten. Es bereitet die benötigten Übersetzungen und Cache-Zustände vor, schaltet Interrupts für den kritischen Abschnitt ab, ändert die Register, führt genau einen 32-Bit-Lese- oder Schreibzugriff aus und stellt die ursprüngliche Konfiguration wieder her. Der Treiber kommentiert ausdrücklich, dass schon ein unerwarteter Speicherzugriff während dieses Fensters auf einer falschen DRAM-Zeile landen kann.

Das ist kein harmloser Diagnosemodus. Ein falsches Mapping kann beliebige laufende Daten beschädigen oder das System sofort hängen lassen.

Eine erlaubte Adresse wird zum Alias für einen gesperrten Bereich

Nehmen wir einen geschützten Bereich mit der physischen Adresse P. Im normalen Mapping M_normal landet P auf einer bestimmten DRAM-Zelle:

M_normal(P) = geheime DRAM-Zelle

Die Schutzlogik erkennt P und blockiert den Zugriff aus dem normalen Betriebssystem. Nach dem Umschalten verwendet der Speichercontroller jedoch ein anderes Mapping M_angriff. Gesucht wird nun eine erlaubte Adresse A, für die gilt:

M_angriff(A) = M_normal(P)

A ist der Alias. Oberhalb des Speichercontrollers sieht der Zugriff unauffällig aus, weil er an eine nicht gesperrte physische Adresse geht. Unterhalb der Prüfung landet er trotzdem an derselben DRAM-Zelle wie P.

Das ist die eigentliche Pointe der Forschung. Sie bricht die Schutzprüfung nicht direkt und errät auch keine Berechtigung. Sie verändert die Bedeutung der Adresse, nachdem die oberen Schichten ihre Arbeit erledigt haben.

Wie der PoC das unbekannte Mapping löst

Die Registerdokumentation allein reicht nicht aus. Laut Repository weichen Details der tatsächlichen XOR-Abbildung je nach Modell und Speicherkonfiguration ab. Außerdem spielen Speichergröße, DIMM-Bestückung und das MMIO-Loch eine Rolle.

Der PoC sammelt deshalb Messpunkte:

Er schaltet in die veränderte Ansicht des Speichers.
Er schreibt einen auffälligen Testwert an eine zufällige Adresse.
Er stellt das normale Mapping wieder her.
Er sucht, an welcher physischen Adresse derselbe Testwert jetzt auftaucht.

Damit entsteht ein Adresspaar für zwei verschiedene Ansichten derselben DRAM-Zelle. Nach ausreichend vielen Paaren rekonstruiert unspaghettify.py die Abbildung als lineares Gleichungssystem über GF(2). Z3 hilft dabei, die unbekannten XOR-Beziehungen der einzelnen Adressbits zu bestimmen.

Z3 löst aus gesammelten Alias-Paaren die DRAM-Adressmatrix

Die mitgelieferte Animation zeigt, wie sich die zunächst unbekannte Matrix mit weiteren Alias-Paaren füllt. Die Idee ähnelt älterer Forschung zur Rekonstruktion undokumentierter DRAM-Adressfunktionen, wird hier aber für gezielte Aliase genutzt.

Aus der gelösten Abbildung kann das Tool für eine geschützte Zieladresse einen erreichbaren Alias berechnen. Für größere Bereiche speichert es die Lösung als Map-Datei. dram_dump liest über diese Maps, dram_poke schreibt darüber.

Die Usage-Dokumentation beschreibt mehrere Sicherheitsprüfungen: Gespeicherte Maps werden mit dem aktuellen Firmware- und Controllerzustand abgeglichen, ein Round-Trip testet die berechneten Aliase, und nicht erreichbare Bereiche werden beim Lesen mit 0xff aufgefüllt. Beim Schreiben ist das Risiko deutlich höher. Trifft ein falscher Alias eine andere DRAM-Zelle, wird dort tatsächlich etwas überschrieben.

Was der Autor aus geschützten Bereichen liest

Das Repository zeigt vier besonders interessante Ziele.

Privater Speicher des AMD Platform Security Processor

Der AMD Platform Security Processor, heute meist AMD Secure Processor genannt, ist ein eigener Sicherheitsprozessor. AMD beschreibt ihn als Grundlage für Secure Boot, Firmwareprüfung und eine isolierte Trusted Execution Environment. Bei aktuellen Ryzen-PRO-Prozessoren soll der Host-SoC nicht auf dessen Speicher zugreifen können. Dieses aktuelle Dokument belegt keine Betroffenheit neuer Ryzen-CPUs, erklärt aber die beabsichtigte Vertrauensgrenze.

Auf der getesteten Family-16h-Plattform lokalisiert dram_carveouts den privaten PSP-DRAM oberhalb von TOP_MEM. Der Autor liest daraus unter anderem Code der RSA-Modular-Exponentiation des fTPM und disassembliert ihn als ARM Thumb-2.

Das belegt Zugriff auf Speicher, den der normale x86-Kernel nicht sehen soll. Es belegt noch nicht, dass private TPM-Schlüssel extrahiert wurden oder dass sich beliebige fTPM-Signaturen erzeugen lassen. Solche Aussagen wären mit dem veröffentlichten Beispiel zu weit gegriffen.

System Management RAM

SMM ist ein besonders privilegierter x86-Betriebsmodus für Firmwareaufgaben. Seine Handler liegen in SMRAM. UEFI beschreibt diesen Bereich aus Sicht von Betriebssystem und Hypervisor bewusst als Black Box.

Der Ansatz knüpft an frühere Forschung von Christopher Domas an. In The Memory Sinkhole zeigte er 2015, wie sich über eine unerwartete Wechselwirkung zwischen APIC-Mapping und Speichercontroller auf SMRAM einwirken lässt. Skitter Creek Bath Salts verwendet nicht denselben Mechanismus, verfolgt aber dieselbe Grundfrage: Welche Annahmen der SMM-Abschirmung brechen, wenn Adressen unterhalb der eigentlichen Zugriffskontrolle anders aufgelöst werden?

Der PoC ermittelt SMBASE, berechnet daraus den Einstieg des SMI-Handlers und liest dessen erste Instruktionen über einen Alias. Damit sieht Ring 0 Code, der gerade vor Ring 0 verborgen sein soll.

Auch hier ist die Trennung wichtig: Das Repository zeigt einen Lesezugriff und stellt eine allgemeine Schreibfunktion bereit. Eine vollständige, dauerhafte SMM-Persistenz oder eine fertige Angriffskette gegen konkrete Firmware ist damit noch nicht demonstriert.

C6-Speicherbereiche

Beim tiefen C6-Stromsparzustand muss pro Kern Zustand gesichert werden. Der Autor findet in einem reservierten DRAM-Bereich unter anderem Werte, die zu CR3, IA32_APIC_BASE, MTRRs und dem gespeicherten Instruction Pointer passen.

Ein Teil davon wäre für Ring 0 ohnehin lesbar. Interessant sind die unbekannten Daten daneben und die Tatsache, dass der gesamte Save-Bereich über denselben Alias-Mechanismus erreichbar wird.

Microcode-Kopie

Wenn ein Kern in C6 wechselt, liegt laut Analyse eine Kopie des geladenen Microcode-Patches im zugehörigen DRAM-Save-Bereich. Das Beispiel liest diese Kopie aus und vergleicht Teile davon erfolgreich mit bekannten Family-16h-Microcode-Dateien.

dram_poke könnte denselben Bereich auch beschreiben. Der Satz „Microcode ist schreibbar“ braucht trotzdem eine Einschränkung: Gezeigt wird eine DRAM-Kopie, die der Kern beim Aufwachen wieder lädt. Welche Validierungen beim Wiederherstellen greifen, wie zuverlässig Änderungen ausführbar werden und ob daraus kontrollierte Microcode-Ausführung entsteht, ist mit der Veröffentlichung noch nicht abschließend geklärt.

Der PoC liest PSP-, SMM- und C6-Daten über berechnete DRAM-Aliase

Originaldemo aus dem Repository: Ohne Alias liefert der Zugriff nur 0xff; mit gelöster Map erscheinen Daten aus PSP-, SMM- und C6-Bereichen.

Was ist wirklich betroffen?

Der wichtigste Filter ist nicht „AMD“, sondern die genaue CPU-Familie und Plattform.

Aussage	Stand am 14.08.2026
AMD Family 16h	Vom Autor entwickelt und getestet. Der mitgelieferte Plattformcheck akzeptiert `AuthenticAMD` mit Family `0x16`.
Bestimmte Family-16h-Modelle und Mainboards	Wahrscheinlich nicht jede Kombination verhält sich identisch. Das Repository enthält Maps für mehrere RAM-Bestückungen, nennt aber keine vollständige Produktmatrix.
AMD Family 17h und neuer	Nicht belegt. Laut Autor fehlen ab 17h die verwendeten Details in den öffentlichen Datenblättern. Registerlayout, Sperren, Fabric und Speicherschutz können anders funktionieren.
Aktuelle Ryzen- und EPYC-Systeme	Durch diesen PoC nicht als betroffen nachgewiesen. Eine pauschale Übertragung wäre unseriös.
Intel, ARM und RISC-V	Der allgemeine Aufbau mit mehreren Adressübersetzungen existiert auch dort. Der konkrete Code, die Register und die gezeigte Ausnutzung sind AMD-Family-16h-spezifisch.
Proxmox VE	Nicht durch Proxmox als Produkt ausgelöst. Entscheidend wären Host-CPU, Firmware, Kernelzugriff und die konkrete Speichercontroller-Implementierung. Übliche aktuelle Proxmox-Hosts fallen nicht allein wegen KVM oder AMD-Hardware in den belegten Bereich.
Virtuelle Maschine ohne Hostzugriff	Der veröffentlichte PoC benötigt Root und ein Kernelmodul auf dem physischen Zielsystem. Ein normaler VM-Gast erreicht diese Register nicht direkt.

Der Plattformcheck im Repository lässt sich zwar mit SKITTER_FORCE=1 umgehen. Das macht eine andere CPU aber nicht kompatibel. Im Gegenteil: Auf einer nicht getesteten Plattform werden hardwarespezifische Registeradressen gerade besonders gefährlich.

Welche CPUs stecken konkret hinter Family 16h?

Eine vollständige Liste bestätigter Einzelmodelle gibt es bisher nicht. Das Repository nennt weder CPU-Modell noch Mainboard und Firmware des Testsystems. Auch die inzwischen umfangreiche Diskussion auf Hacker News löst diese Frage nicht auf. Dort wird Family 16h zutreffend als alte, vor Zen erschienene Niedrigverbrauchsfamilie eingeordnet. Das ist aber keine unabhängige Reproduktion.

Der Code selbst zieht die Grenze ausschließlich über CPUID: Herstellerkennung AuthenticAMD und Familie 0x16, also 22 in dezimaler Linux-Ausgabe. Die Modellnummer wird nicht geprüft. AMD dokumentiert für Family 16h zwei Modellbereiche:

CPUID-Modellbereich	Zugehörige Plattformen	Konkrete Produktbeispiele
`00h–0Fh` (dezimal 0–15)	Jaguar; unter anderem Kabini, Temash und Kyoto	AM1: Athlon 5150/5350 und Sempron 2650/3850; mobile A-/E-Series wie A4-1200, A4-1350, A6-1450, A6-5200 und E1-2100; Opteron X1150/X2150; Embedded G-Series wie GX-210JA/HA, GX-217GA, GX-415GA, GX-416RA und GX-420CA
`30h–3Fh` (dezimal 48–63)	Puma+; unter anderem Beema, Mullins sowie Embedded-Varianten wie Steppe Eagle	Mobile APUs wie A6-6310, A4-6210, A10 Micro-6700T und A4 Micro-6400T; Embedded G-Series wie GX-412HC und GX-412TC. Letzterer steckt beispielsweise in den Netzwerkboards PC Engines apu2, apu3 und apu4.

Diese Namen sind Beispiele für Family-16h-Produkte, keine Liste erfolgreich angegriffener CPUs. Der veröffentlichte Plattformcheck würde sie aufgrund der Familie passieren lassen. Ob der gesamte Ablauf einschließlich PSP-, SMRAM- und C6-Zugriff auf jedem Modell, Board und Firmwarestand funktioniert, ist damit nicht belegt. Gerade die beiden Modellbereiche unterscheiden sich: Die 2014er Beema-, Mullins- und Steppe-Eagle-Plattformen brachten den ARM-basierten PSP mit; bei älteren Family-16h-Produkten sind daher nicht automatisch alle vier Demonstrationen aus dem Repository vorhanden.

Auch der Produktname allein reicht nicht. AMD hat Bezeichnungen wie Athlon, Sempron, A-Series und Embedded G-Series über mehrere CPU-Familien hinweg verwendet. Ein Athlon 5350 fällt in Family 16h; ein neuer Athlon auf Zen-Basis nicht. Ebenso gehört ein PC Engines apu1 mit G-T40E zur älteren Bobcat-Generation und nicht zur Zielgruppe dieses PoC, während apu2/3/4 mit GX-412TC in den Family-16h-Kandidatenkreis fallen.

Auf einem Linux-System lässt sich die Einordnung gefahrlos und ohne Kernelmodul prüfen:

LC_ALL=C lscpu | grep -E 'Vendor ID:|CPU family:|Model:|Model name:'

Stehen dort AuthenticAMD und CPU family: 22, ist das System nach der groben Prüfung des PoC ein Family-16h-Kandidat. Die Werte Model: 0 bis 15 gehören zum ersten, Model: 48 bis 63 zum zweiten Bereich. Jeder andere Family-Wert liegt außerhalb der vom Autor angegebenen Zielplattform. Das Kommando liest nur die bereits vom Kernel bereitgestellten CPU-Daten und verändert keine Hardwarekonfiguration.

Zur Abgrenzung: AMD FX sowie viele ältere A-Series-Generationen wie Trinity, Richland, Kaveri oder Carrizo gehören zu Family 15h und werden vom veröffentlichten Code nicht akzeptiert. Ryzen und EPYC beginnen bei Family 17h beziehungsweise späteren Familien. Spielekonsolen mit angepassten AMD-SoCs lassen sich ebenfalls nicht aus der PC-Liste ableiten; dort unterscheiden sich Sicherheitsprozessor, Speicheraufbau und Ausführungsumgebung erheblich.

Ist „Root erforderlich“ eine Entwarnung?

Für einen normalen Serverangriff ist Root bereits ein schwerer Schaden. Der Angreifer kann Prozesse manipulieren, Daten lesen und viele Sicherheitsfunktionen abschalten. In diesem Sinn erhöht Skitter Creek Bath Salts nicht plötzlich das Risiko jeder ungepatchten Webanwendung.

Trotzdem ist Root nicht dasselbe wie PSP oder SMM. Hardwaregestützte Vertrauensanker sollen bestimmte Geheimnisse und Firmwarepfade auch vor einem kompromittierten Betriebssystem schützen. AMD selbst beschreibt den Secure Processor als isolierte Grundlage für Secure Boot und Schlüsselverwaltung. Wenn ein privilegierter Host diese Speichergrenze über den DRAM-Controller umgehen kann, ist das sicherheitstechnisch relevant.

Praktisch hängt die Angriffskette vor dem PoC davon ab, ob ein Angreifer überhaupt eigenen Kernelcode laden kann. Linux kann das deutlich erschweren:

Erzwungene Kernelmodul-Signaturen lassen nur Module zu, deren Signatur der Kernel prüfen kann.
Kernel-Lockdown im Modus integrity sperrt Funktionen, über die Userspace den laufenden Kernel verändern kann. Der Modus confidentiality schränkt zusätzlich das Auslesen vertraulicher Kernelinformationen ein.
kernel.modules_disabled=1 verhindert nach dem Umschalten dauerhaft das weitere Laden und Entladen von Modulen bis zum nächsten Neustart.

Diese Maßnahmen beheben keinen Fehler im Speichercontroller. Sie nehmen dem veröffentlichten Werkzeug aber seinen vorgesehenen Einstieg, solange der Angreifer nicht schon Secure Boot, Signaturprüfung oder den laufenden Kernel selbst umgehen kann.

Was derzeit noch offen ist

Die Veröffentlichung ist erst wenige Stunden alt. Entsprechend lang ist die Liste der offenen Fragen:

Auf welchem genauen Family-16h-Modell, Board, BIOS und AGESA-Stand wurden die Beispiele aufgenommen?
Lässt sich der Angriff auf allen relevanten Family-16h-Modellen reproduzieren?
Gibt es eine von AMD vorgesehene Sperre oder Firmwarekonfiguration, die auf manchen Plattformen greift?
Welche neueren AMD-Generationen besitzen vergleichbare, aus dem Host erreichbare Umschaltpunkte?
Verhindern Speicherverschlüsselung oder geänderte Fabric-Architekturen auf neueren Systemen brauchbare Klartext-Aliase?
Welche Prüfungen greifen beim Wiederladen der C6-Microcode-Kopie?
Lassen sich Schlüsselmaterial oder kontrollierte SMM-/PSP-Ausführung zuverlässig demonstrieren?
Wird AMD ein Security Bulletin, eine CVE oder eine technische Stellungnahme veröffentlichen?

Der Autor verweist im README auf einen Beitrag mit dem Titel „Spaghettifying DRAM“. Das Material ist dort weiterhin als „Coming Soon“ markiert. Eine SecTor-2026-Programmliste führt inzwischen den vollständigen Titel „Spaghettifying DRAM: Breaking Everything with Memory Collision Exploitation“ und kennzeichnet den Vortrag als On-Demand-Beitrag. Das ist eine zusätzliche Bestätigung des Vortragstitels, aber noch keine technische Zweitquelle. Ein öffentliches Paper oder Folienset haben wir weiterhin nicht gefunden.

Auch das Repository selbst hat sich seit dem ersten Stand verändert. Der zweite Commit überarbeitet nur die README-Prosa. Unter anderem wurde die pauschale Formulierung entfernt, die Plattform kehre „entirely unscathed“ zurück. Kernelmodul, Userspace-Tools, Analyseskripte und Beispieldaten blieben unverändert. Der vorsichtige Ton dieses Artikels ändert sich dadurch nicht.

Einordnung für Betreiber

Für aktuelle Serverflotten besteht kein Grund für hektische Wartungsfenster. Es gibt weder einen belegten Angriff auf moderne EPYC- oder Ryzen-Systeme noch einen Remote-Pfad. Wer aus der Veröffentlichung jetzt „alle AMD-Server kompromittierbar“ macht, überspringt den größten Teil des Threat Models.

Aufmerksamkeit verdient das Thema trotzdem in drei Situationen:

Alte Embedded- oder Spezialplattformen: Family-16h-Systeme können noch in Appliances, Industrieumgebungen oder lange gepflegten Spezialgeräten laufen. Dort ist ein Austausch nicht immer kurzfristig möglich.
Hohe Anforderungen an Plattformvertrauen: Wenn fTPM, Secure Boot oder SMM ausdrücklich eine Trennung vom Host-Kernel herstellen sollen, ist ein privilegierter Bypass dieser Grenze wichtiger als auf einem gewöhnlichen Testsystem.
Forschung und Forensik: Der Ansatz zeigt, dass eine physische Adresse keine endgültige Beschreibung des Speicherorts ist. Threat Models für Firmware und Coprozessoren müssen die konfigurierbaren Stufen darunter mitdenken.

Unsere pragmatische Reihenfolge wäre:

CPU-Familie und genaue Hardware inventarisieren, bevor irgendeine Betroffenheit behauptet wird.
Auf Family-16h-Systemen prüfen, wer Kernelmodule laden oder signieren kann.
Secure Boot, Kernel-Lockdown und Modulsignaturen nicht nur konfigurieren, sondern ihre wirksame Durchsetzung testen.
Kritische Altplattformen von nicht vertrauenswürdigen Administrationspfaden und Workloads trennen.
AMD-Bulletins, das angekündigte Vortragsmaterial und unabhängige Reproduktionen beobachten.
Den PoC ausschließlich auf entbehrlicher Laborhardware mit externem Recovery-Pfad untersuchen.

Warum wir den PoC nicht zur Schnellprüfung empfehlen

Bei vielen CVEs ist ein ungefährlicher Versionscheck oder ein lesender Test möglich. Hier ist schon die Funktionsweise destruktiv: Der Speichercontroller wird im laufenden Betrieb umkonfiguriert. Die Dokumentation erwähnt eigens einen Remote-Collector, der hängende Testsysteme über eine schaltbare Stromversorgung neu startet.

Ein erfolgreicher Lauf ist außerdem kein einfacher Ja/Nein-Test. Die Abbildung hängt von der RAM-Bestückung und dem Firmwarezustand ab, muss mit Messwerten gelöst und anschließend kalibriert werden. Ein Fehler beim Lesen produziert falsche Daten. Ein Fehler beim Schreiben beschädigt eine unbekannte Speicherstelle.

Auf einem Produktivsystem gibt es deshalb keinen vernünftigen Grund, SKITTER_FORCE=1, --dangerously-skip-calibration oder Schreibzugriffe auszuprobieren. Für die erste Einordnung reichen CPU-Familie, Bootkette und Modulrichtlinien vollkommen aus.

Fazit

Skitter Creek Bath Salts ist keine breit ausnutzbare neue Serverlücke. Der veröffentlichte PoC ist auf eine alte AMD-Familie zugeschnitten, benötigt volle Hostrechte und arbeitet in einem Bereich, in dem ein kleiner Fehler das System abstürzen oder Speicher beschädigen kann.

Die Forschung ist trotzdem bemerkenswert. Sie zeigt sehr anschaulich, dass eine Schutzgrenze nur so stark ist wie die tiefste veränderbare Übersetzung darunter. PSP, SMRAM und C6 können aus Sicht des Kernels unsichtbar sein. Wenn der Speichercontroller einer erlaubten Adresse anschließend eine andere Bedeutung gibt, reicht diese Unsichtbarkeit allein nicht mehr.

Ob daraus ein Problem für neuere Plattformen wird, ist offen. Genau das sollte die nächste Phase klären: reproduzierbare Hardwaredaten, eine Herstellerreaktion und eine saubere Trennung zwischen dem belegten Family-16h-Angriff und der allgemeinen Architekturthese.

Update-Log

2026-08-14, 02:28 Uhr CEST: Hacker-News-Diskussion und AMD-Unterlagen zu beiden Family-16h-Modellbereichen ausgewertet. Konkrete Produktbeispiele, klare Ausschlüsse und einen gefahrlosen lokalen CPUID-Check ergänzt. Weiterhin fehlt eine bestätigte SKU-/Firmware-Testmatrix.
2026-08-14, 01:22 Uhr CEST: Zweiten Repository-Commit geprüft. Er ändert nur den README-Text, nicht den PoC. Den angekündigten vollständigen Vortragstitel und Domas’ frühere SMM-Forschung als weitere Quellen ergänzt. Weiterhin keine CVE, kein AMD-Bulletin und keine unabhängige Reproduktion gefunden. Artikel veröffentlicht.
2026-08-13, 17:32 Uhr CEST: Erster Stand nach Veröffentlichung des Repositories. Code, Usage-Dokumentation, Demo-Medien, AMD-Dokumentation und verwandte Forschung geprüft. Noch keine CVE, kein AMD-Bulletin und keine unabhängige Reproduktion gefunden.