Für eine erfolgreiche Ausnutzung nennt Qualys drei Bedingungen. Priorität beim Patchen sollten demnach exponierte und Multi-Tenant-Systeme haben, also Hosts mit XFS und aktiviertem Reflink, auf denen lokal nicht vertrauenswürdiger Code ausgeführt werden kann — etwa über eine Shell, einen CI-Job oder einen kompromittierten Dienst.
Die Advisory nennt als standardmäßig potenziell betroffene Installationen Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux und CloudLinux 8, 9 und 10, Fedora Server ab Version 31, Amazon Linux 2023 sowie Amazon-Linux-2-Abbilder ab Dezember 2022. RHEL-7-Dateisysteme sind nicht betroffen, weil sie älter sind als die Reflink-Unterstützung in XFS. Debian, Ubuntu, SLES und openSUSE verwenden XFS für das Root-Dateisystem in der Regel nicht standardmäßig; dort besteht das Risiko nur, wenn ein Administrator XFS mit aktiviertem Reflink bei der Installation gewählt hat.
Ob das Root-Dateisystem betroffen sein kann, lässt sich laut Quelle mit „xfs_info / | grep reflink=“ prüfen. Gibt der Befehl „reflink=1“ zurück, ist eine der Voraussetzungen erfüllt. Dieselbe Prüfung empfiehlt sich auch für andere eingehängte XFS-Volumes, wenn sich eine geschützte Datei und ein vom Angreifer beschreibbares Verzeichnis auf demselben Dateisystem befinden.
Technisch basiert der Fehler auf einem Zeitfenster während eines Sperrzyklus. Ein Angreifer klont zunächst mit FICLONE eine root-eigene Datei in eine temporäre Datei; dafür ist nur Lesezugriff auf die Quelldatei nötig. Anschließend startet er konkurrierende O_DIRECT-Schreibzugriffe auf den Klon. Da XFS-Reflinks Copy-on-Write verwenden, verweisen beide Dateien zunächst auf dieselben physischen Blöcke.
Der Kernel liest die Zuordnung des Datenbereichs unter einer Inode-Sperre und übergibt sie an xfs_reflink_fill_cow_hole(), das diese Sperre kurz freigibt, um Transaktionsspeicher zu reservieren. In dieser Lücke kann ein zweiter Schreiber den Copy-on-Write-Vorgang abschließen und den Klon auf einen neuen Block umbiegen. Nach dem erneuten Sperren arbeitet der erste Schreiber laut Upstream-Patch mit veralteten Zuordnungen weiter: „Die Zuordnungen sind veraltet, sobald wir die ILOCK erneut erhalten.“ Das Ergebnis: Daten, die eigentlich in den Klon geschrieben werden sollten, landen in der geschützten Zieldatei.
The Hacker News berichtet, dass der Patch zwei Hilfsfunktionen anfasst: xfs_reflink_fill_cow_hole() und xfs_reflink_fill_delalloc(). Bei beiden speichert der Fix vor dem Freigeben der Sperre ip->i_df.if_seq und liest den Datenbereich mit xfs_bmapi_read() erneut ein, falls sich der Zähler verändert hat. Direct I/O umgeht den Seitencache und besitzt hier keinen Mechanismus zur erneuten Prüfung. Weil der Schreibzugriff die Ziel-Inode selbst umgeht, ändern sich die Metadaten nicht; laut den Forschern erzeugten ihre Tests weder Kernel-Warnungen noch Logeinträge.
Auf dem Testsystem gewann die Race Condition laut Qualys meist in unter zehn Sekunden. Die veröffentlichte Demonstration entfernt auf einem Standard-RHEL-10.2-System das Root-Passwort. Eigenständigen Exploit-Code hat Qualys nicht veröffentlicht. Red Hats Tracker vermerkte am 22. Juli jedoch einen öffentlichen Proof of Concept und verwies auf die Advisory in der oss-security-Liste, die Race Condition und Ausnutzungsschritte vollständig beschreibt. Keiner der Anbieter, die die Schwachstelle verfolgen, hatte zum Zeitpunkt der Veröffentlichung eine aktive Ausnutzung gemeldet.
Qualys zufolge wurde die Lücke von einem KI-Modell gefunden. Das Unternehmen setzte Claude Mythos Preview, ein nur eingeschränkt zugängliches Frontier-Modell von Anthropic, auf den Kernel an und forderte es laut Technical Advisory auf, „eine Schwachstelle ähnlich Dirty COW zu finden“. Das Modell identifizierte demnach die Race Condition, schrieb einen funktionierenden Root-Exploit und entwarf die Advisory. Die Forscher reproduzierten das Ergebnis anschließend auf einer unveränderten Fedora-Server-44-Installation, überprüften die Argumentation des Modells und koordinierten die Offenlegung mit den Upstream-Entwicklern.
Red Hat hat Kernel-Advisories mit der Einstufung „Important“ für betroffene RHEL-8-, RHEL-9- und RHEL-10-Streams veröffentlicht. Die Errata erschienen bereits ab dem 14. Juli: RHSA-2026:39179 und RHSA-2026:39180 für RHEL 8 sowie RHSA-2026:39494 für RHEL 10; erweiterte Support- und SAP-Streams folgten bis zum 17. Juli. Da die Abdeckung vom jeweiligen Stream abhängt, sollte laut Quelle für die konkrete Release-Linie geprüft werden, ob eine passende Advisory vorliegt.
Debians Tracker führte den Fix am 23. Juli in trixie-security als Kernel 6.12.96-1 und in unstable als 7.1.4-1. Als verwundbar markiert waren dort weiterhin trixies Basiskernel 6.12.94-1 und forkys 7.1.3-1 sowie bookworm und bullseye einschließlich ihrer Sicherheitszweige. Eine praktische Abschwächung gibt es laut Qualys nicht: Weder eine Mount-Option noch ein sysctl kann XFS-Reflinks nachträglich abschalten. In den Tests des Unternehmens verhinderten auch SELinux im Enforcing-Modus, seccomp, Kernel-Lockdown und Container-Grenzen den Angriff nicht. Hersteller-Update allein genügt zudem nicht im laufenden Betrieb: Der aktualisierte Kernel muss installiert, das System neu gestartet und anschließend der gepatchte Kernel tatsächlich ausgeführt werden.