RefluXFSeen nieuwe Linux-kernelfout bekendgemaakt op 22 juli en gevolgd als CVE-2026-64600laat een onbevoegde lokale gebruiker bestanden die eigendom zijn van de root op een XFS-bestandssysteem overschrijven en permanente root-toegang verkrijgen.
Qualys zei dat standaardinstallaties van Red Hat Enterprise Linux en zijn afgeleiden, Fedora Server en Amazon Linux kunnen voldoen aan de voorwaarden voor exploitatie.
Het bedrijf demonstreerde de race tegen /etc/passwd en setuid-root binaire bestanden. Het overschrijven komt terecht op de bloklaag. Het overleeft een herstart en laat het eigendom, de machtigingen, de tijdstempels en de setuid-bit van het doel onaangeroerd, dus een aangepast binair setuid-root-bestand draait nog steeds als root.
De oplossing is op 16 juli samengevoegd en Linux-leveranciers zijn begonnen met het leveren van backported-kernels. De patch traceert de bug naar Linux 4.11 in 2017: Fixes: tagnaamgeving commit 3c68d44a2b49 en een stabiel backportverzoek gemarkeerd # v4.11.
Wie wordt blootgesteld
Voor exploitatie zijn drie voorwaarden nodig:
- Het systeem draait op Linux 4.11 of hoger zonder de RefluXFS-fix.
- Het XFS-bestandssysteem is gemaakt met
reflink=1. - Het leesbare doel en een door de aanvaller schrijfbare map bevinden zich op hetzelfde XFS-bestandssysteem.
Qualys zei dat het eerst blootgestelde en multi-tenant systemen zou patchen, wat betekent dat elke XFS-host met reflink-functionaliteit waarop niet-vertrouwde code lokaal kan worden uitgevoerd, hetzij via een shell, een CI-taak of een gecompromitteerde service.
Het advies vermeldt de standaardinstallaties die aan deze voorwaarden kunnen voldoen: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux en CloudLinux 8, 9 en 10, Fedora Server 31 en hoger, Amazon Linux 2023 en Amazon Linux 2 images vanaf december 2022. RHEL 7-bestandssystemen worden niet beïnvloed omdat ze dateren van vóór de XFS-reflink-ondersteuning.
Debian, Ubuntu, SLES en openSUSE gebruiken over het algemeen niet standaard XFS voor het rootbestandssysteem. Ze worden alleen zichtbaar als een beheerder tijdens de installatie XFS heeft gekozen met reflink ingeschakeld.
Controleer het rootbestandssysteem:
xfs_info / | grep reflink=
reflink=1 betekent dat aan voorwaarde twee is voldaan. Voer dezelfde controle uit op elk ander gekoppeld XFS-volume waarop een beveiligd bestand en een door een aanvaller schrijfbare map het bestandssysteem delen.

De verouderde mapping
Een aanvaller kloont een bestand dat eigendom is van de root naar een scratch-bestand met FICLONEdat alleen leestoegang op de bron nodig heeft, en vervolgens gelijktijdig racet O_DIRECT schrijft tegen de kloon. XFS-reflinks gebruiken copy-on-write, dus beide bestanden verwijzen in eerste instantie naar dezelfde fysieke schijfblokken.
De kernel leest de data-fork mapping onder de inode-lock en geeft deze door xfs_reflink_fill_cow_hole()welke cycli vergrendelen om transactieruimte te reserveren.
Een tweede schrijver kan tijdens die periode de copy-on-write-bewerking voltooien en het gekloonde bestand opnieuw toewijzen aan een nieuw blok. Wanneer de eerste schrijver de vergrendeling opnieuw verkrijgt, wordt de copy-on-write-vork vernieuwd, maar blijft hij de oude data-fork-toewijzing gebruiken.
De upstream-patch beschrijft de mislukking duidelijk: “de mappings zijn verouderd zodra we de ILOCK opnieuw verkrijgen.”
Dat verouderde adres verwijst nu naar een blok dat alleen eigendom is van het oorspronkelijke beveiligde bestand. XFS beschouwt het blok als niet-gedeeld en staat direct schrijven toe, zodat gegevens die bedoeld zijn voor de kloon van de aanvaller in plaats daarvan in het doel terechtkomen.
Het is een controle-en-gebruik-fout tijdens een vergrendelingscyclus. De vraag naar de gedeelde status zelf is correct; wat het vraagt is een blokadres dat is vastgelegd voordat het slot werd vrijgegeven.
The Hacker News ontdekte dat de patch twee helpers raakt, xfs_reflink_fill_cow_hole() En xfs_reflink_fill_delalloc(). De tweede heeft hetzelfde lock-cycle-patroon en komt niet voor in het Qualys-advies. In beide zijn de fix-snapshots ip->i_df.if_seq voordat het slot wordt verwijderd en de datavork opnieuw wordt gelezen xfs_bmapi_read() als de teller beweegt.
Directe I/O slaat de paginacache over en heeft geen hervalidatiehaak, zodat het schrijven op schijf terechtkomt. Omdat het de doelinode volledig omzeilt, veranderen de metadata nooit, en de onderzoekers zeiden dat hun tests geen kernelwaarschuwing of loginvoer opleverden.
Op de testmachine werd de race doorgaans binnen de tien seconden gewonnen. De gepubliceerde demo verwijdert het root-wachtwoord op een standaard RHEL 10.2-box.
Qualys zei dat een AI-model de fout heeft gevonden. Het bedrijf richtte Claude Mythos Preview, Anthropic’s grensmodel met beperkte toegang, op de kernel en vroeg het, volgens zijn technisch advies, “een kwetsbaarheid te vinden die vergelijkbaar is met Dirty COW.”
Het model lokaliseerde de race, schreef een werkende root-exploit en stelde het advies op. Onderzoekers reproduceerden het vervolgens op een standaard Fedora Server 44-installatie, controleerden de redenering van het model en coördineerden de openbaarmaking stroomopwaarts.
Het is niet de eerste verouderde kernelbug van het team dit jaar. Qualys heeft er veel van gevonden. Een dag eerder onthulde het een snap-confine-fout in Ubuntu Desktop, CVE-2026-8933waarbij twee races een lokale gebruiker root laten worden bij standaardinstallaties. In mei werd een negen jaar oude bug gevonden in de ptrace-controles van de kernel.
Patchen en vervolgens opnieuw opstarten
Red Hat heeft kerneladviezen met een belangrijke beoordeling uitgebracht voor de getroffen RHEL 8-, 9- en 10-streams. De errata begonnen op 14 juli, acht dagen vóór de gecoördineerde openbaarmaking: RHSA-2026:39179 en RHSA-2026:39180 voor RHEL 8 en RHSA-2026:39494 voor RHEL 10, met uitgebreide ondersteuning en SAP-streams tot en met 17 juli.
De dekking is streamspecifiek, dus zorg ervoor dat er een advies bestaat voor uw exacte release. Iedereen die deze errata op tijd toepaste, was gedekt voordat RefluXFS een naam had. Controleer de datums van uw patches voordat u blootstelling aanneemt.
De bugtracker van de leverancier archiveert de fout onder de titel “kernel: XFS-gegevenscorruptie met behulp van reflink.” Het item werd op 10 juli automatisch geïmporteerd en beschreef het probleem aanvankelijk als mogelijke gegevensbeschadiging door het opnieuw koppelen van een bestand.
Vanaf 23 juli vermeldde de tracker van Debian de oplossing in trixie-security als kernel 6.12.96-1 en in onstabiel als 7.1.4-1. De basiskernel van Trixie 6.12.94-1 en vorken 7.1.3-1 waren nog steeds kwetsbaar, net als boekenwurm en bullseye, inclusief hun beveiligingstakken.
Er is geen mount-optie of sysctl die XFS-reflinks uitschakelt nadat een bestandssysteem is aangemaakt, en Qualys zei dat er geen praktische beperking of tijdelijke configuratiewijziging beschikbaar is. SELinux in de Enforcing-modus, seccomp, kernel-lockdown en containergrenzen konden dit allemaal niet stoppen tijdens de tests van het bedrijf. Geheugenbeveiligingen zoals KASLR en SMEP zijn nooit toegepast: dit is een bloklaagschrijven, geen geheugencorruptie.
Eén schijnbare grens is er niet één. De race start alleen als het blok van het doelwit niet wordt gedeeld, dus een bestand dat door een beheerder al opnieuw is gekopieerd, kan niet worden geraakt. Het advies zegt dat een gebruiker zonder rechten die toestand kan resetten door te rennen chshen dat het onwaarschijnlijk is dat setuid-root binaire bestanden überhaupt opnieuw zijn gekoppeld.
Qualys heeft geen stand-alone exploitcode gepubliceerd. De tracker van Red Hat registreerde op 22 juli een openbare proof-of-concept, verwijzend naar het advies op de oss-securitylijst, waarin de race en de exploitatiestappen volledig worden beschreven. Geen van de leveranciers die de fout opspoorden, had op het moment van schrijven melding gemaakt van uitbuiting in het wild.
The Hacker News heeft contact opgenomen met Red Hat voor commentaar op de beoordeling van de impact van de fout en met Qualys voor meer details over de bevinding, en zal dit verhaal bijwerken met eventuele reacties.
Het installeren van het pakket vervangt niet de kernel die al in het geheugen draait. Pas de leveranciersupdate toe, start het systeem opnieuw op en controleer of de vaste kernel wordt uitgevoerd.