Am 22. Juli wurde die Schwachstelle CVE-2026-64600 (RefluXFS) im Linux-Kernel offengelegt: Eine Race Condition in der XFS-reflink-Subsystem ermöglicht es einem nicht privilegierten lokalen Benutzer, Dateien zu überschreiben, die root gehören, und sich dauerhaft privilegierten Zugriff zu verschaffen. Der Bug ist in Kerneln seit Version 4.11 (2017) vorhanden. Nach Angaben der Qualys-Forscher sind die Voraussetzungen für eine Ausnutzung auf Standardinstallationen von Red Hat Enterprise Linux und abgeleiteten Distributionen, Fedora Server und Amazon Linux erfüllt. Der Fix wurde am 16. Juli in den Hauptzweig des Kernels eingepflegt, die Hersteller haben mit der Auslieferung aktualisierter Kernel begonnen. Ein öffentlicher PoC-Exploit ist verfügbar, doch eine Ausnutzung in freier Wildbahn wurde zum Zeitpunkt der Offenlegung nicht beobachtet. Die einzig wirksame Maßnahme ist ein Kernel-Update mit anschließendem Neustart.
Mechanismus der Schwachstelle
Die Schwachstelle gehört zur Klasse TOCTOU (time-of-check-to-time-of-use) – ein Check-then-Use-Fehler über einen Lock-Zyklus. Ein Angreifer klont eine root-gehörende Datei in seine eigene Arbeitsdatei mithilfe des Systemaufrufs FICLONE, für den Leserechte auf die Quelldatei genügen. Der XFS-reflink-Mechanismus verwendet Copy-on-Write: Beide Dateien verweisen anfangs auf dieselben physischen Blocke des Datenträgers.
Der Kernel liest das Data-Fork-Mapping unter Sperre des Inodes ein und übergibt es an die Funktion xfs_reflink_fill_cow_hole(), die diese Sperre aufhebt, um Transaktionsspeicher zu reservieren. In diesem Zeitfenster kann ein zweiter paralleler Schreiber die Copy-on-Write-Operation abschließen und die geklonte Datei auf einen neuen Block umlegen. Wenn der erste Schreiber die Sperre erneut erlangt, aktualisiert er den COW-Fork, verwendet aber weiterhin die veraltete Blockadresse aus dem Data-Fork.
Wie im Patch beschrieben wird, „werden die Mappings veraltet, sobald wir ILOCK erneut erfassen“. Die veraltete Adresse verweist nun auf einen Block, der ausschließlich zur ursprünglichen, geschützten Datei gehört. XFS betrachtet den Block als nicht geteilt und erlaubt eine direkte Schreiboperation – die für den Klon des Angreifers bestimmten Daten landen in der Root-Zieldatei.
Kritisch ist: Schreiben über Direct I/O umgeht den Page Cache und den Ziel-Inode vollständig, sodass die Metadaten der Datei – Besitzer, Rechte, Zeitstempel, setuid-Bit – unverändert bleiben. Nach Angaben der Forscher wird eine modifizierte setuid-root-Binärdatei weiterhin mit Root-Rechten ausgeführt. Die Tests zeigten weder Kernel-Warnungen noch Log-Einträge. Auf der Testmaschine wurde das Rennen nach eigenen Angaben in weniger als zehn Sekunden gewonnen.
Der Patch betrifft zwei Funktionen – xfs_reflink_fill_cow_hole() und xfs_reflink_fill_delalloc(). Die Korrektur speichert den Wert des Zählers ip->i_df.if_seq vor dem Freigeben der Sperre und liest den Data-Fork über xfs_bmapi_read() erneut ein, falls sich der Zähler geändert hat.
Wer dem Risiko ausgesetzt ist
Für eine Ausnutzung müssen gleichzeitig drei Bedingungen erfüllt sein:
- Das System läuft auf einem Linux-Kernel 4.11 oder neuer ohne RefluXFS-Fix.
- Das XFS-Dateisystem wurde mit dem Parameter
reflink=1erstellt. - Die Zieldatei (mit Leserechten) und ein für den Angreifer beschreibbares Verzeichnis befinden sich auf demselben XFS-Dateisystem.
Nach Angaben von Qualys können Standardinstallationen der folgenden Systeme diese Bedingungen erfüllen:
- RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux in den Versionen 8, 9 und 10
- Fedora Server 31 und neuer
- Amazon Linux 2023 und Amazon Linux 2-Images seit Dezember 2022
RHEL 7 ist nicht betroffen – seine Dateisysteme stammen aus der Zeit vor der Unterstützung von XFS reflink. Die Distributionen Debian, Ubuntu, SLES und openSUSE verwenden standardmäßig kein XFS für das Root-Dateisystem und sind nur dann gefährdet, wenn bei der Installation XFS mit aktiviertem reflink explizit ausgewählt wurde.
Zur Überprüfung führen Sie aus:
xfs_info / | grep reflink=
Das Ergebnis reflink=1 bedeutet, dass die zweite Bedingung für eine Ausnutzung erfüllt ist. Die gleiche Prüfung sollte für alle eingehängten XFS-Volumes erfolgen, auf denen geschützte Dateien und für Schreibzugriff freigegebene Verzeichnisse koexistieren können.
Fehlende Workarounds
Qualys berichtet, dass es keine praktikablen temporären Gegenmaßnahmen gibt. Es existiert keine Mount-Option und kein sysctl-Parameter, der reflink auf einem bereits angelegten Dateisystem deaktivieren würde. Während der Tests der Forscher verhinderten weder SELinux im Enforcing-Modus, noch seccomp, noch Kernel Lockdown, noch Container-Grenzen die Ausnutzung. Speicherschutzmechanismen (KASLR, SMEP) sind nicht anwendbar: Es handelt sich um einen Schreibzugriff auf Blockgeräteebene, nicht um eine Speicherbeschädigung.
Die einzige Einschränkung ist, dass das Rennen nur dann greift, wenn der Zielblock der Datei nicht geteilt (unshared) ist. Wie im Advisory angegeben, kann ein nicht privilegierter Benutzer diese Bedingung jedoch selbst herbeiführen, etwa durch das Ausführen von chsh, und setuid-root-Binärdateien sind in typischen Konfigurationen ohnehin keine reflink-Kopien.
Rolle von KI bei der Entdeckung
Qualys gibt an, dass die Schwachstelle mithilfe eines KI-Modells – Claude Mythos Preview von Anthropic – entdeckt wurde, das mit der Aufgabe betraut wurde, eine Dirty-COW-ähnliche Schwachstelle zu finden. Nach Angaben des Unternehmens lokalisierte das Modell das Race, schrieb einen funktionierenden Exploit zur Erlangung von Root-Rechten und erstellte einen Entwurf des Advisory. Die Forscher reproduzierten den Bug anschließend auf einer Standardinstallation von Fedora Server 44, prüften die Logik des Modells und koordinierten die Offenlegung mit den Kernel-Entwicklern. Diese Aussage stammt ausschließlich von Qualys und ist nicht unabhängig bestätigt.
Status der Patches
Red Hat hat Empfehlungen mit dem Schweregrad Important für die betroffenen RHEL-8-, -9- und -10-Streams veröffentlicht. Die Errata wurden ab dem 14. Juli veröffentlicht – acht Tage vor der koordinierten Offenlegung: RHSA-2026:39179 und RHSA-2026:39180 für RHEL 8, RHSA-2026:39494 für RHEL 10, mit zusätzlichen Aktualisierungen für Extended-Support- und SAP-Streams bis zum 17. Juli. Die Abdeckung hängt vom jeweiligen Stream ab – es muss geprüft werden, ob ein Erratum für den exakt eingesetzten Release vorliegt.
Der Eintrag im Bugtracker von Red Hat wurde am 10. Juli automatisch unter dem Titel „kernel: XFS data corruption using reflink“ importiert und beschrieb das Problem zunächst als mögliche Datenbeschädigung. Der öffentliche PoC wurde am 22. Juli im Tracker vermerkt.
Nach Angaben des Debian Security Trackers vom 23. Juli ist der Fix in trixie-security (Kernel 6.12.96-1) und in unstable (7.1.4-1) verfügbar. Das Basiskernel von trixie (6.12.94-1), forky (7.1.3-1) sowie bookworm und bullseye, einschließlich ihrer Security-Branches, sind weiterhin als verwundbar markiert.
Empfehlungen
- Priorisieren Sie Mehrbenutzersysteme und Hosts, auf denen nicht vertrauenswürdiger Code lokal ausgeführt werden kann (CI/CD, Shared Server, kompromittierte Services).
- Installieren Sie den aktualisierten Kernel Ihres Herstellers. Organisationen, die die Red-Hat-Errata vor dem 22. Juli eingespielt haben, sind bereits geschützt.
- Starten Sie das System neu nach der Installation des Pakets – das Update ersetzt nicht den im Speicher laufenden Kernel.
- Prüfen Sie, dass das System mit dem gepatchten Kernel gebootet hat:
uname -r. - Überprüfen Sie alle XFS-Volumes auf
reflink=1, nicht nur das Root-Dateisystem.
RefluXFS ist eine Schwachstelle ohne Workarounds: Weder SELinux noch Containerisierung noch seccomp blockieren die Ausnutzung. Angesichts eines öffentlichen PoC und einer detaillierten Beschreibung der Angriffsschritte in der oss-security-Mailingliste ist das Zeitfenster für ein sicheres Nichtstun minimal. Die einzige verlässliche Maßnahme ist, einen aktualisierten Kernel zu installieren und jeden Host mit XFS reflink neu zu starten, wobei per uname -r zu prüfen ist, dass das System auf einer gepatchten Version läuft.
