Neue RefluXFS-Sicherheitslücke unter Linux überdauert Neustarts und bleibt in den Protokollen unentdeckt

Heute Nachmittag live: Wir analysieren RefluXFS gemeinsam mit einem Experten für Linux-Patches, einschließlich der neuesten Informationen zu den Maßnahmen der Hersteller und der Vorgehensweise, um die Sicherheitslücke ohne Neustart zu schließen. Hier ansehen →

Die Kurzfassung

Zur Langfassung springen ↓

Worum es geht: RefluXFS, registriert unter der Kennung CVE-2026-64600, ist eine Race Condition im „Copy-on-Write“-Pfad des XFS-Dateisystems im Linux-Kernel. Sie ermöglicht es einem lokalen Benutzer ohne Sonderrechte, einen Schreibvorgang von einer Kopie mit symbolischem Link zurück in den physischen Festplattenblock der Originaldatei umzuleiten, sodass ein Angreifer eine Datei ändern kann, die dem Root-Benutzer gehört und die er zwar lesen, aber nicht schreiben darf. Zur ausführlichen Version springen →

Auswirkung: Lokale Rechteausweitung auf Root. Qualys demonstrierte dies anhand von /etc/passwd und setuid-root-Binärdateien auf einem standardmäßigen Enterprise-Linux-System und hob den Passwortschutz des Root-Kontos auf einem unmodifizierten RHEL 10.2-System innerhalb von Sekunden auf. Der Schreibvorgang erfolgt unterhalb des normalen Inode-Schreibpfads, sodass Eigentümer, Berechtigungen, Zeitstempel und das Setuid-Bit des Ziels erhalten bleiben, der Vorgang einen Neustart übersteht und in den Tests von Qualys keine Einträge im Kernel-Protokoll erzeugt wurden. Zur Langfassung springen →

Schweregrad: Zum Zeitpunkt der Erstellung dieses Artikels lag noch kein öffentlicher CVSS-Wert vor. Behandeln Sie die Schwachstelle dennoch als hochprioritär: Die Ausnutzung ist zuverlässig, erfordert lediglich ein normales lokales Konto, umgeht gängige Sicherheitsmaßnahmen und führt zu dauerhaften Root-Rechten. Red Hat stuft die Schwachstelle als „Wichtig“ ein. Zur ausführlichen Version springen →

Wer ist betroffen: Linux-Kernel auf Basis von Version 4.11 oder höher, die den anfälligen XFS-Code enthalten und nicht über den Patch verfügen, auf einem XFS-Dateisystem, das mit Reflink-Unterstützung erstellt wurde, wobei sich eine schreibgeschützte, aber lesbare Datei und ein Verzeichnis, in das ein Angreifer schreiben kann, dieses Dateisystem teilen. Dies beschreibt die Standardkonfiguration unter RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux sowie CloudLinux 8, 9 und 10, außerdem unter Fedora Server 31 und höher, Amazon Linux 2023 und Amazon Linux 2-Images ab Dezember 2022. RHEL 7 stammt aus der Zeit vor der Einführung von XFS-Reflink und ist daher von dieser Standardkonfiguration nicht betroffen. Zur ausführlichen Version springen →

Status: Am 22. Juli 2026 von Qualys öffentlich bekannt gegeben und im Rahmen des „Project Glasswing“ von Anthropic mithilfe von KI entdeckt. Der Upstream-Fix wurde am 16. Juli integriert, und die Anbieter haben Kernel mit Backports ausgeliefert. Einige Korrekturen für Unternehmen wurden bereits vor der Offenlegung als reguläre Kernel-Updates veröffentlicht, sodass ein Host die Korrektur möglicherweise bereits enthält, auch wenn CVE-2026-64600 in dem Update nicht erwähnt wurde. Zur Langfassung springen →

So gehen Sie jetzt vor: Es gibt keine risikofreie Konfigurationsumgehung. Red Hat hat eine vorübergehende SystemTap-Abhilfe veröffentlicht, doch die eigentliche Lösung ist ein gepatchter Kernel: Überprüfen Sie, ob jedes XFS-Dateisystem Reflinks verwendet, wenden Sie den korrigierten Kernel für genau Ihre Version an und starten Sie den Rechner neu, oder wenden Sie einen KernelCare-Patch ohne Neustart an (der automatisch im Hintergrund für die Benutzer bereitgestellt wird). Zur ausführlichen Version springen →

xfs_info / | grep reflink=

Ein Ergebnis von „reflink=1“ bestätigt die Erfüllung der Dateisystemvoraussetzung. Wiederholen Sie diesen Vorgang für andere eingebundene XFS-Volumes, die sowohl geschützte Dateien als auch für Angreifer beschreibbare Verzeichnisse enthalten.

RefluXFS verstößt gegen eines der grundlegendsten Prinzipien eines Dateisystems: dass man eine geschützte Datei zwar lesen, aber nicht überschreiben darf.

Der Angreifer öffnet niemals die Datei /etc/passwd oder eine Setuid-Root-Binärdatei zum Schreiben. Linux würde dies sofort verweigern. Stattdessen weist er XFS an, eine Kopie der Datei mit einem Referenzlink an einem Ort zu erstellen, den er kontrolliert, und führt dann zwei direkte Schreibvorgänge gleichzeitig auf diese Kopie aus. Aufgrund einer veralteten Blockzuordnung im Kernel kann einer dieser Schreibvorgänge statt in der Kopie in der ursprünglichen, geschützten Datei landen. Der Angreifer schreibt in eine Datei, die er kontrolliert, doch die ursprüngliche, dem Root-Benutzer gehörende Datei wird verändert.

Diese eine Primitive reicht aus, um das Root-Passwort zu löschen, Authentifizierungsdaten zu überschreiben oder Angreifercode in eine setuid-root-Binärdatei einzuschleusen, sodass diese als Root ausgeführt wird. Bei einer Standardinstallation von RHEL 10.2 gelang dies Qualys innerhalb von Sekunden.

Ein Detail ist besonders im Hinblick auf die Live-Stream-Diskussion erwähnenswert. RefluXFS wurde im Rahmen von Anthropics „Project Glasswing“ entdeckt: Qualys wies „Claude Mythos Preview“ auf den Kernel hin und beauftragte das Programm, nach einer Race-Condition im Stil von „Dirty COW“ zu suchen; anschließend reproduzierten die eigenen Forscher den Befund, überprüften jede Behauptung und führten die koordinierte Offenlegung durch. KI beschleunigte die Suche; Menschen bestätigten und veröffentlichten den Befund. Betrachten Sie dies als einen Ausblick darauf, wohin die Suche nach Kernel-Fehlern in Zukunft führen wird – und nicht als Ausnutzung per Knopfdruck.

Zwei Dinge werden Sie dennoch dazu verleiten, dies so niedrig einzustufen. Das erste ist die Formulierung im ursprünglichen Hersteller-Update, das als einfache Korrektur für „XFS-Datenkorruption“ ausgeliefert wurde und sich wie ein Ärgernis hinsichtlich der Datenintegrität liest. Es handelt sich um eine zuverlässige lokale Root-Primitive. Das zweite ist reflink selbst, was nach einer exotischen Option klingt, die niemand aktiviert. Es ist seit Jahren die mkfs-Standardeinstellung für das Root-Dateisystem der RHEL-Familie, sodass Sie auf einem System im Auslieferungszustand die Bedingung bereits erfüllen, ohne danach fragen zu müssen.

Mit XFS-Reflinks können zwei Dateien auf dieselben physischen Festplattenblöcke verweisen, ohne dass die Daten dupliziert werden. Wenn eine Datei geschrieben wird, führt XFS ein „Copy-on-Write“-Verfahren durch: Es weist der geänderten Datei einen neuen Block zu, kopiert die Daten, ordnet die Datei neu zu und setzt die Referenzanzahl des ursprünglichen Blocks auf null. Die ursprüngliche Datei soll dabei unverändert bleiben.

RefluXFS entsteht, wenn zwei Schreibvorgänge gleichzeitig diese Sequenz durchlaufen.

[Attacker reflink-clones a readable root-owned file]
                     |
                     v
[Both files temporarily reference the same disk blocks]
                     |
                     v
[Two concurrent O_DIRECT writes race against the clone]
                     |
                     v
[XFS drops the inode lock to reserve transaction space]
                     |
                     v
[One path keeps using a stale physical block mapping]
                     |
                     v
[The write reaches the original protected file's disk block]
                     |
                     v
[Protected file changes with no normal write to its inode]

Der anfällige Code liest den Daten-Fork der Datei unter der Inode-Sperre und gibt die Sperre anschließend frei, um Speicherplatz für das Transaktionsprotokoll zu reservieren. Während dieser Lücke kann ein zweiter Schreiber seinen eigenen „Copy-on-Write“-Zyklus abschließen, den Klon auf einen neuen Block umzuordnen und die Referenzanzahl des ursprünglichen Blocks auf eins herabsetzen. Wenn der erste Schreiber die Sperre erneut erwirbt, überprüft er erneut, ob der Block noch gemeinsam genutzt wird, vergleicht dies jedoch mit der physischen Adresse, die er vor dem Aufheben der Sperre erfasst hat. Diese Adresse ist eine veraltete Zuordnung zum Data-Fork. XFS erkennt einen Wert von eins, schließt daraus, dass der Block privat ist, und schreibt in ihn hinein, obwohl dieser Block nun ausschließlich zur geschützten Quelldatei gehört.

Da O_DIRECT den Seiten-Cache umgeht, findet keine erneute Überprüfung statt und der Schreibvorgang wird auf die Festplatte geschrieben. Es handelt sich um ein Wettlaufproblem zwischen dem Zeitpunkt der Überprüfung und dem Zeitpunkt der Nutzung innerhalb eines Inode-Lock-Zyklus. Die Berechtigungsprüfung war zu keinem Zeitpunkt fehlerhaft. Der Kernel hat lediglich auf eine Blockadresse reagiert, die inzwischen veraltet war.

Durch diesen Fix liest XFS die Zuordnung der Data-Fork erneut ein, nachdem es festgestellt hat, dass sich die Zuordnung möglicherweise geändert hat, während die Sperre aufgehoben war:

Before:
read mapping -> release lock -> mapping changes -> reuse stale mapping -> wrong file overwritten

After:
read mapping -> release lock -> mapping changes -> reread mapping -> write follows current mapping

Der Bericht von Qualys lokalisiert den Verlust der Sperre in der Funktion `xfs_reflink_allocate_cow()`. Der Mainline-Commit mit dem Titel „xfs: resample the data fork mapping after cycling ILOCK“, der am 16. Juli integriert wurde, führt eine Neuabtastung der Zuordnung in den betroffenen CoW-Helfern durch. Dabei werden weder das Format auf der Festplatte noch das Layout der Kernel-Datenstrukturen verändert, was später für das Patchen ohne Neustart von Bedeutung ist.

Das Überschreiben erfolgt auf Blockebene und umgeht den normalen Schreibpfad auf Inode-Ebene der geschützten Datei. Dadurch werden mehrere Signale umgangen, die üblicherweise zur Erkennung von Dateiänderungen verwendet werden:

• Das Ziel behält seinen ursprünglichen Eigentümer und seine Zugriffsrechte bei.
• Das Setuid-Bit bleibt erhalten, sodass eine manipulierte Setuid-Root-Binärdatei weiterhin als Root ausgeführt wird.
• Die Zeitstempel müssen diese Änderung nicht widerspiegeln.
• Bei der pfadbasierten Überwachung von Dateiaktivitäten wird ein Schreibvorgang auf das geschützte Ziel selbst möglicherweise nicht erfasst.
• Die geänderten Daten bleiben auch nach einem Neustart auf der Festplatte erhalten.
• Qualys hat keine entsprechende Kernel-Warnung oder keinen entsprechenden Protokolleintrag festgestellt.

Aus diesem Grund ist RefluXFS schlimmer als ein vorübergehender Fehler, der zu einer Speicherbeschädigung führt. Es handelt sich um eine dauerhafte Änderungsprimitive auf der Festplatte, die die meisten Signale, auf die Verteidiger achten, unberührt lässt. Ein Tool zur Dateiintegritätsprüfung, das den Dateiinhalt hasht, kann dies zwar noch erkennen. Tools, die sich auf Metadaten, pfadbasierte Prüfprotokolle oder Kernel-Warnungen stützen, können dies jedoch nicht.

Es müssen alle drei Bedingungen erfüllt sein:

1. Auf dem System läuft ein betroffener Linux-Kernel auf Basis von Version 4.11 oder höher, ohne den entsprechenden Patch.
2. Das betreffende XFS-Dateisystem wurde mit Reflink-Unterstützung angelegt.
3. Ein lesgeschütztes Ziel und ein Verzeichnis, in das Angreifer schreiben können, befinden sich auf demselben Dateisystem.

Überprüfen Sie das Root-Dateisystem sowie jedes eingebundene XFS-Volume, auf dem nicht vertrauenswürdiger lokaler Code ausgeführt werden kann, da ein separates Datenvolume auch dann gefährdet sein kann, wenn das Root-Dateisystem selbst nicht gefährdet ist:

xfs_info / | grep reflink=

Eine Ausgabe mit „reflink=1“ bedeutet, dass die Voraussetzung für das Dateisystem erfüllt ist.

Qualys führt RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux sowie CloudLinux 8, 9 und 10 als häufig betroffene Unternehmensdistributionen auf, ebenso wie Fedora Server 31 und spätere Versionen, Amazon Linux 2023 und die ab Dezember 2022 veröffentlichten Amazon Linux 2-AMIs.

Debian, Ubuntu, SLES, openSUSE und Fedora Workstation verwenden standardmäßig kein XFS für das Root-Verzeichnis; dies ist nur dann der Fall, wenn ein Administrator XFS mit aktiviertem Reflink gewählt hat. Die Dateisysteme von RHEL 7 stammen aus einer Zeit vor der Unterstützung von XFS-Reflink und fallen daher nicht unter die hier beschriebene Standardkonfiguration.

Versuchen Sie nicht, sich mit logischen Überlegungen in „Sicherheit“ zu wiegen. Der Race-Condition-Angriff wird nur ausgelöst, wenn der Zielblock zunächst nicht gemeinsam genutzt wird, was zu der Annahme verleiten könnte, dass eine Datei, die Sie bereits per „reflink“ kopiert haben, immun ist. Ein Benutzer ohne Sonderrechte kann diesen Zustand jedoch zurücksetzen, und es ist unwahrscheinlich, dass setuid-root-Binärdateien überhaupt per „reflink“ kopiert wurden. Diese scheinbare Einschränkung bietet keine verlässliche Sicherheitsgrenze.

Unser Kernel-Team hat die Sicherheitslücke bei den folgenden Builds reproduziert und überprüft, dass die entsprechenden Hersteller-Builds die Korrektur enthalten:

Es handelt sich hierbei um spezifische Punktversionen. Der Geltungsbereich ist streamspezifisch; überprüfen Sie daher die Sicherheitsempfehlung für genau Ihre Version, anstatt von einer ähnlichen Version auszugehen.

Standard-Layouts von Enterprise Linux machen Angriffe praktikabel

Die Anforderung, dass sich alles im selben Dateisystem befinden muss, klingt einschränkend. Bei einer typischen Unternehmensinstallation ist dies jedoch nicht der Fall, da durch das standardmäßige „Single-Root-XFS“-Layout alles auf einem Volume gespeichert wird:

• Ausführbare Dateien mit Root-Rechten unter /usr/bin
• Authentifizierungsdaten unter /etc
• Das weltweit beschreibbare Verzeichnis /tmp
• Benutzer-Home-Verzeichnisse unter /home

Dadurch erhält ein Benutzer ohne Sonderrechte sowohl lesbare Ziele von hohem Wert als auch beschreibbaren Arbeitsspeicher auf demselben reflink-fähigen Dateisystem. Stellen Sie sich die Umgebungen vor, in denen dies zum Tragen kommt: einen gemeinsam genutzten Build-Host, einen CI-Runner, der das ausführt, was beim letzten Merge-Request gepusht wurde, einen Multi-Tenant-Knoten, auf dem containerisierte oder eingeschränkte Workloads auf geeignete Pfade im XFS-Dateisystem desselben Hosts zugreifen können, oder einen Entwickler-Rechner, auf dem nicht vertrauenswürdige Abhängigkeiten ausgeführt werden. In jedem dieser Fälle reicht ein gewöhnliches Konto aus, um den Exploit auszuführen.

Es handelt sich hierbei um eine lokale Rechteausweitung auf dem Host, nicht um eine Remote-Codeausführung und auch nicht um einen Ausbruch vom Gast zum Hypervisor. Ein Angreifer muss zunächst lokale Codeausführung erlangen. Sobald ihm dies gelungen ist, wandelt RefluXFS diesen Einstiegspunkt in Root-Rechte auf dem Host um.

Warum gängige Maßnahmen zur Linux-Absicherung dies nicht verhindern

RefluXFS ist kein herkömmlicher Exploit, der eine Beschädigung des Kernel-Speichers ausnutzt. Er missbraucht normale Dateisystemoperationen, um einen Schreibvorgang auf den falschen physischen Block zu lenken, weshalb viele gängige Abwehrmaßnahmen ihn übersehen:

• SELinux: Qualys konnte die Sicherheitslücke unter SELinux im „Enforcing“-Modus reproduzieren.
• KASLR, SMEP und SMAP: Diese Mechanismen schützen vor Speicherbeschädigungen, nicht vor der Zuweisung von Dateisystemblöcken, weshalb sie niemals zum Einsatz kommen.
• Kernel-Lockdown: Er schränkt normale Reflink- oder Direct-I/O-Operationen für nicht privilegierte Benutzer in keiner Weise ein.
• Container und Namespaces: Sie sperren den Zugriff auf den anfälligen Dateisystempfad nicht automatisch.
• Seccomp: Typische Profile lassen die gewöhnlichen Dateioperationen zu, die der Angriff nutzt.
• Neustart ohne Aktualisierung: Die beschädigte Datei bleibt erhalten, und durch das Booten desselben anfälligen Kernels bleibt die Sicherheitslücke bestehen.

Es sind keine besonderen Funktionen erforderlich. Kein CAP_SYS_ADMIN, kein privilegierter Namespace, keine ungewöhnliche Hardware, keine benutzerdefinierte Kernel-Konfiguration. Die Voraussetzungen bezüglich XFS, reflink und „same-filesystem“ gelten weiterhin, sind jedoch auf vielen betroffenen Enterprise-Linux-Installationen standardmäßig vorhanden.

Es gibt keine risikofreie Konfigurationslösung, aber Red Hat hat eine vorübergehende Abhilfemaßnahme für die Laufzeit veröffentlicht.

„reflink“ wird bei der Erstellung des XFS-Dateisystems ausgewählt. Es gibt keine Mount-Option und keinen sysctl-Eintrag, mit denen ein bestehendes Dateisystem mit „reflink=1“ in ein Dateisystem ohne „reflink“ umgewandelt werden kann, und die Neuerstellung des Dateisystems ist keine Notfallmaßnahme für den Produktivbetrieb. Das Entfernen der setuid-Bits aus „su“, „sudo“ oder „pkexec“ beeinträchtigt den normalen Betrieb und stellt keine gezielte Abhilfe dar.

Red Hat Product Security hat eine vorläufige SystemTap-Abhilfemaßnahme veröffentlicht, die den XFS-Reflink-Einstiegspunkt abfängt und Ref-Link-Operationen dazu zwingt, einen Fehler wegen einer nicht unterstützten Operation zurückzugeben. Ein ähnlicher Ansatz ist mit kprobes möglich. Dies blockiert den anfälligen Ref-Link-Pfad, verändert jedoch das Verhalten des Dateisystems und kann Anwendungen beeinträchtigen, die auf Ref-Link-Klonen angewiesen sind. Testen Sie die Maßnahme daher zunächst in einer Testumgebung. Betrachten Sie dies als vorübergehenden Schutz für Systeme, die nicht sofort gepatcht werden können, und nicht als Ersatz für einen korrigierten Kernel.

Die eigentliche Lösung ist ein korrigierter Kernel, unabhängig davon, ob ein Neustart erfolgt oder nicht.

Die Installation eines Kernel-Pakets hat keine Auswirkungen auf den bereits im Arbeitsspeicher laufenden Kernel. Bei einem herkömmlichen Hersteller-Update gehen Sie wie folgt vor: Installieren Sie das Kernel-Update für genau Ihre Version, starten Sie den Rechner neu und vergewissern Sie sich, dass der Rechner mit dem neuen Kernel gestartet ist.

uname -r

Für die oben aufgeführten Streams lauten die getesteten festen Builds 4.18.0-553.144.1.el8_10, 5.14.0-687.26.1.el9_8 und 6.12.0-211.34.1.el10_2. Überprüfen Sie Ihren laufenden Kernel anhand des Sicherheitshinweises für Ihre jeweilige Distribution, Ihren Stream und Ihre Architektur.

Es gibt zwei Fallstricke, die es zu vermeiden gilt. Beurteilen Sie die Situation nicht anhand des neuesten Pakets auf der Festplatte, sondern anhand des aktuell laufenden Kernels. Gehen Sie außerdem nicht davon aus, dass jeder nach dem 16. Juli kompilierte Kernel die Korrektur enthält, da die Versionsnummern der Distributionen nicht mit den Upstream-Veröffentlichungen übereinstimmen und einige Zweige die Korrektur bereits früher zurückportiert haben. Überprüfen Sie dies anhand des Herstellerhinweises für den jeweiligen Zweig. Da einige Hersteller die Korrektur bereits vor der Veröffentlichung der CVE ausgeliefert haben, geben CVE-basierte Scanner möglicherweise keinen vollständigen Überblick über den historischen Patch-Status.

Rebootloses Patchen

RefluXFS eignet sich gut für Patches, die ohne Neustart durchgeführt werden können. Die Korrektur besteht aus einer gezielten Änderung der Art und Weise, wie der XFS-Code die Blockzuordnung nach dem Durchlaufen der Inode-Sperre aktualisiert, ohne dass dabei das Format auf der Festplatte geändert wird oder Kernel-Datenstrukturen systemweit ersetzt werden müssen.

In der öffentlichen Sicherheitsempfehlung von Qualys wird empfohlen, einen korrigierten Kernel zu installieren und das System neu zu starten; dabei wird zu Recht darauf hingewiesen, dass „reflink“ auf einem bestehenden Live-Dateisystem nicht deaktiviert werden kann.

KernelCare verfolgt einen anderen Ansatz zur Behebung des Problems: Es wendet die Korrektur des zugrunde liegenden XFS-Codes direkt auf den laufenden Kernel an, anstatt zu versuchen, „reflink“ zu deaktivieren oder die Konfiguration des Dateisystems zu ändern.

Der anfällige CoW-Pfad führt dann nach dem Sperrzyklus eine erneute Abtastung der Data-Fork-Zuordnung durch, ohne dass ein Wartungsfenster oder ein Neustart der Arbeitslast erforderlich ist. Es handelt sich um einen reinen Kernel-Fehler, bei dem keine Komponente der Userspace-Bibliothek als Ursache in Frage kommt.

KernelCare-Benutzer haben in der Regel die Patches so eingerichtet, dass alle neuen Korrekturen automatisch im Hintergrund in bestimmten Intervallen – beispielsweise alle vier Stunden – installiert werden. Die Benutzer können jedoch auch jeden Patch aus dem Produktions-Feed anwenden, sobald dieser freigegeben wurde:

kcarectl --update

Überprüfen Sie die CVE-Zuordnung, anstatt sich auf das Erstellungsdatum zu verlassen, da ein nach Mitte Juli kompilierter Kernel diese Korrektur nicht automatisch enthält:

kcarectl --patch-info | grep 'CVE-2026-64600'

Falls ein Patch noch über den Test-Feed für Ihre Kernel-Familie bereitgestellt wird, überprüfen Sie bitte die Verfügbarkeit, bevor Sie sich auf die Unterstützung ohne Neustart verlassen, und starten Sie in der Zwischenzeit den korrigierten Hersteller-Kernel neu.

Holen Sie sich KernelCare noch heute →

Erkennung und Überprüfung von Vorfällen

Es gibt keinen einzigen verlässlichen RefluXFS-Indikator; betrachten Sie daher jeden der folgenden Punkte als Anhaltspunkt und nicht als Beweis.

Die effektivste Überprüfung auf der Festplatte nutzt den blinden Fleck des Fehlers aus: Der Inhalt hat sich geändert, die Metadaten jedoch nicht. Bei der Paketüberprüfung wird der Dateiinhalt per Hash-Funktion überprüft, sodass der Fehler auch dann erkannt wird, wenn „mtime“ und „mode“ einwandfrei erscheinen. Beginnen Sie mit der Paketüberprüfung für sicherheitsrelevante Pakete:

rpm -V shadow-utils sudo util-linux polkit

Eine 5 in der Zeichenkette des Verifizierungsergebnisses weist auf eine Nichtübereinstimmung des Digests hin. Bei einer setuid-root-Binärdatei oder einer Kernkonfigurationsdatei ohne entsprechenden T-Zeitstempel oder M-Moduswechsel entspricht dies der Art von Änderungen, die RefluXFS hinterlassen kann. Auf Systemen der Debian-Familie übernimmt „debsums -c“ dieselbe Funktion. Die Paketüberprüfung deckt nicht alle wichtigen veränderbaren Konfigurationsdateien ab; ergänzen Sie sie daher durch vertrauenswürdige Sicherungskopien, Konfigurationsmanagement-Aufzeichnungen und bekanntermaßen korrekte Datei-Hashes.

Konzentrieren Sie sich auf die besonders wertvollen Ziele:

/etc/passwd   /etc/shadow   /etc/sudoers
/usr/bin/su   /usr/bin/sudo   /usr/bin/passwd   /usr/bin/pkexec

Achten Sie dann auf folgende Verhaltensmerkmale: unerwartete passwortlose oder neue privilegierte Konten, geänderte Felder des Root-Kontos, setuid-Programme, deren Inhalt nicht mehr mit dem installierten Paket übereinstimmt, unerklärliche SSH-Schlüssel, Privilegienerweiterungen ohne entsprechendes sudo-, Login- oder Authentifizierungsereignis, Spitzen bei gleichzeitigen Direkt-I/O-Zugriffen durch einen nicht privilegierten Prozess sowie das Klonen geschützter Dateien mittels reflink an Orte, an denen der Benutzer Schreibrechte hat.

Ein normaler Zeitstempel oder ein unveränderter Berechtigungsmodus bedeutet nicht, dass eine Datei bereinigt wurde. Wenn während des Sicherheitsfensters nicht vertrauenswürdiger Code auf einem anfälligen Host ausgeführt wurde, sollten Sie dies als mögliche Beeinträchtigung der Integrität betrachten und Konten, Authentifizierungskonfigurationen und Dienste genauer unter die Lupe nehmen, anstatt ein unauffälliges Kernel-Protokoll als Beweis für die Sicherheit zu werten.

Warum RefluXFS wichtig ist

RefluXFS wird leicht unterschätzt, da drei Details auf den ersten Blick einschränkend wirken. Es ist lokal und nicht remote. Es benötigt XFS. Es benötigt reflinks.

Im Enterprise-Linux-Umfeld beschreiben diese drei Punkte die Standardumgebung, und die Maschinen, auf die dies zutrifft, sind genau diejenigen, auf denen der Code anderer ausgeführt wird: Mandanten, Build-Pipelines, Container, Plugins und kompromittierte Dienste.

Die Schwachstelle überschreitet zudem die Sicherheitsgrenze auf ungewöhnliche Weise. Kein direkter Schreibzugriff auf die geschützte Datei, kein SELinux, das umgangen werden muss, keine Payload im Kernel-Speicher. Der Kernel schreibt einfach gültige, vom Angreifer kontrollierte Daten in den falschen Festplattenblock, und das Ergebnis ist dauerhaft, verfügt über Root-Rechte und verläuft unbemerkt.

Auch hier lässt sich eine prozessbezogene Lehre ziehen, die Sie in Ihre Triage-Warteschlange einfließen lassen sollten. Für viele Administratoren war das erste öffentlich verwertbare Signal möglicherweise ein gewöhnliches Kernel-Update eines Anbieters, das vor der CVE-Veröffentlichung bereitgestellt und als Korrektur für eine XFS-Datenkorruption beschrieben wurde. Das ist das Muster „zuerst stillschweigend beheben, dann erst CVE melden“, und eine Warteschlange, die sich ausschließlich auf Sicherheitserrata stützt, hätte eine lokale LPE mit Root-Rechten als routinemäßige Wartungsmaßnahme abgelegt. Behalten Sie alle Kernel-Bugfix-Meldungen im Auge, nicht nur diejenigen, die als sicherheitsrelevant gekennzeichnet sind.

Bei Systemen, die auf herkömmliche Weise gepatcht werden, installieren Sie das Hersteller-Update und stellen Sie sicher, dass der Rechner tatsächlich damit hochfährt. Bei Serverflotten, bei denen Notneustarts ein eigenes Betriebsrisiko darstellen, schließt ein „rebootless“ Patch von KernelCare die Sicherheitslücke im XFS-Pfad des laufenden Kernels, ohne dass Knoten heruntergefahren oder Arbeitslasten unterbrochen werden müssen.

Holen Sie sich KernelCare noch heute →

Zeitleiste

Referenzen

• Qualys, „RefluXFS: Eine lokale Privilegienerweiterung im Linux-Kernel auf Root-Rechte unter XFS (CVE-2026-64600)“, 22. Juli 2026: https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
• Technischer Hinweis von Qualys: „RefluXFS: Lokale Rechteausweitung über einen Race-Condition bei XFS-Reflink-Direct-I/O“, oss-security 2026/Q3, 22. Juli 2026
• Vorläufige SystemTap-Abhilfemaßnahme von Red Hat Product Security, Mailingliste „oss-security“ (Thread zu CVE-2026-64600)
• Red Hat CVE-Seite, CVE-2026-64600: https://access.redhat.com/security/cve/cve-2026-64600
• Red Hat-Sicherheits-Errata RHSA-2026:39179 und RHSA-2026:39180 (RHEL 8), RHSA-2026:39494 (RHEL 10)
• Upstream-Korrektur: „xfs: Neuberechnung der Data-Fork-Zuordnung nach einem ILOCK-Zyklus“ (Commit 2f4acd0), integriert am 16. Juli 2026
• Fehlerverursachender Commit 3c68d44a2b49, „xfs: Zuweisung von Direct-I/O-COW-Blöcken in iomap_begin“ (Linux 4.11)
• The Hacker News, „Neun Jahre alte RefluXFS-Sicherheitslücke unter Linux gewährt lokalen Benutzern Root-Rechte bei Standard-RHEL-Installationen“: https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html
• Betroffene Sicherheitshinweise für die Distributionen AlmaLinux, Rocky Linux, Oracle Linux, Fedora und Amazon Linux