Interrupt Injection umgeht Spectre-v2-Schutz auf Intel- und AMD-CPUs unter Linux

Trujillo und Yan bezeichnen die zugrunde liegende Angriffsklasse als TONTOU, kurz für „Zeitpunkt der Neutralisierung bis zum Zeitpunkt der Nutzung“, in Anlehnung an TOCTOU-Race-Conditions aus der Software. Der Kern ihrer Argumentation: Alle diese Schutzmaßnahmen gehen davon aus, dass zwischen dem Neutralisieren eines Vorhersagezustands und dessen späterer Nutzung nichts Feindliches dazwischen ausgeführt wird. Interrupts brechen diese Annahme, weil sie nahezu jederzeit eintreffen können und Linux es Nutzern erlaubt, sie mit Nanosekunden-Granularität zu terminieren.

Die bestehenden Abwehrmechanismen säubern oder isolieren den Zustand des Branch Predictors, damit ein zuvor trainierter Angreifer keine Kernel-Verzweigung beeinflussen kann. Intel setzt dazu beim Eintritt in den Kernel auf eIBRS und je nach Prozessor zusätzlich auf eine Schleife zum Leeren des Branch History Buffer oder auf die BHI_DIS_S-Steuerung. AMD setzt unmittelbar vor jeder Rückkehr aus dem Kernel auf saferet. Wenn aber während des Zeitfensters zwischen Schutz und Nutzung eine Interrupt-Behandlung läuft, wird der Rückkehrpfad des Interrupts selbst zum Teil der Spectre-v2-Abwehr.

Auf Zen 2 ist dieses Zeitfenster laut den Forschern nur zwei Instruktionen beziehungsweise sechs Byte breit. Um ihre Chancen zu erhöhen, verdrängten sie diese Bytes per parallelem Hyperthread aus L1- und L2-Cache und verlangsamten so deren Ausführung. Außerdem wählten sie den Systemaufruf write, weil sie dabei zwei Register kontrollieren konnten. Interrupts trafen in 5 bis 12 Prozent der Fälle innerhalb dieses Fensters ein; in rund 2 Prozent der Fälle standen dabei auch die von den Angreifern kontrollierten Register zur Verfügung.

Sobald der Interrupt in diesem Fenster landete, wurde der Handler selbst zum Trainings-Gadget. Zusammen mit Inception (CVE-2023-20569) ließ sich so der Return Stack Buffer mit einem von den Angreifern gewählten Ziel füllen. Gerade diese 2023 bekannt gewordene AMD-Schwachstelle ist der Grund, weshalb saferet überhaupt existiert. In den Tests traten Fehlvorhersagen in Kernel-Code auf drei der vier getesteten Systeme auf: mit Erfolgsraten von 0,75 Prozent auf Zen 2, 0,22 Prozent auf Intel Arrow Lake und 0,037 Prozent auf Cascade Lake Refresh. Auf Zen 4 traten in diesem Test keine Fehlvorhersagen auf, und auf Intel demonstrierten die Forscher keinen vollständigen End-to-End-Datenabfluss, weil dafür zusätzlich bereits ein nutzbares Disclosure-Gadget im Kernel vorhanden sein müsste.

Die Forscher sehen das jedoch nicht als grundsätzliche Hürde. Gegenüber The Hacker News erklärten sie, Fehlvorhersagen seien „eine notwendige, aber keine hinreichende Bedingung für einen Spectre-Angriff“. Da frühere Arbeiten bereits gezeigt hätten, dass Disclosure-Gadgets in Kerneln existieren, hielten sie einen End-to-End-Angriff auch auf Intel für möglich, wenn ihre Interrupt-Injection-Technik mit dieser Vorarbeit kombiniert werde.

Trujillo und Yan meldeten das Problem am 5. Februar an AMD und Intel. AMD teilte ihnen mit, einen Kernel-Patch zu planen; laut MIT wurde dieser inzwischen ausgeliefert und kommt über ein normales Betriebssystem-Update. Im Linux-Kernel existiert die Korrektur bereits: Der Commit „x86/bugs: Make Safe-RET robust against interrupt injection“ vom 2. Juni stammt von Borislav Petkov und wurde gemeinsam mit David Kaplan entwickelt, beide AMD-Ingenieure. Der Commit beschreibt den Angriff in denselben Begriffen wie die Forscher: Während Safe-RET injizierte Interrupts könnten „die sichere Rückkehrsequenz neutralisieren und potenziell durch spekulative Ausführung zu Datenabfluss führen“. Die Korrektur setzt den Registerzustand so, als wäre die Safe-RET-Sequenz bereits abgeschlossen worden, und vermeidet nach der Rückkehr aus dem Interrupt die Ausführung einer RET-Instruktion.

AMD veröffentlichte am 6. August zudem das Bulletin AMD-SB-7061 mit dem Titel „Safe RET Interrupt Vulnerability“ und nennt darin Zen-1- bis Zen-4-Prozessoren als betroffen. In der Zusammenfassung heißt es, ein Angreifer mit Codeausführung auf einem betroffenen System könne „zu einem präzisen Zeitpunkt einen Interrupt injizieren, um Safe RET zu stören“, was diesen Schutz „möglicherweise schwächen und zu einer Offenlegung von Informationen führen kann“. AMD ergänzt, das Problem scheine „mit der Linux-Implementierung der Safe-RET-Abwehr zusammenzuhängen“. Das Bulletin nennt Trujillo als Hinweisgeber und erklärt, das Verhalten sei auf Zen 1 und Zen 2 demonstriert worden; Zen 3 und Zen 4 würden nahegelegt, aber nicht demonstriert. Die von The Hacker News eingesehene Arbeit berichtet wiederum nur von AMD-Tests auf Zen 2 und Zen 4. Im Abschnitt zu betroffenen Produkten und Gegenmaßnahmen listet AMD lediglich Prozessoren auf, aber weder eine Patch-Referenz noch eine Kernel-Version oder CVE.

Intel zahlte laut der Arbeit einen freiwilligen Bug-Bounty-Bonus, hält eine Gegenmaßnahme aber nicht für erforderlich. Dem Papier zufolge erklärte Intel, die Ausnutzbarkeit hänge „von vielen Faktoren“ ab und die Technik falle unter bestehende Hinweise. The Hacker News prüfte dazu INTEL-SA-00598 in der zuletzt im Mai 2025 aktualisierten Fassung und fand dort keinen Hinweis auf Interrupts. Weder AMDs Bulletin noch die MIT-Ankündigung verweisen auf den Kernel-Commit. Ohne CVE und ohne benannte Kernel-Version müssen Administratoren laut Bericht den Betreff des Commits kennen, um zu prüfen, ob ein System bereits abgesichert ist. Der Kernel meldet den SRSO-Status über /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow; als The Hacker News die zugehörige Dokumentation am 6. August prüfte, wurden Interrupts dort nicht erwähnt.