"the mappings are stale as soon as we reacquire the ILOCK."
What RefluXFS is and how it escalates privilege
RefluXFS, tracked as CVE-2026-64600 and disclosed on July 22, 2026, is a Linux kernel race condition that lets an unprivileged local user overwrite root-owned files on XFS filesystems created with reflink support enabled and thereby gain persistent root access. The overwrite occurs at the block layer, survives a reboot, and leaves file ownership, permissions, timestamps, and the setuid bit unchanged — meaning a modified setuid-root binary still runs as root.
How the exploit works: stale mappings, copy-on-write, and direct I/O
The vulnerability arises when an attacker clones a root-owned file using FICLONE (which requires only read access on the source) and then races concurrent O_DIRECT writes against that clone. XFS reflinks use copy-on-write so both files initially point to the same physical disk blocks. The kernel reads the data-fork mapping under the inode lock and calls xfs_reflink_fill_cow_hole(), which releases the lock to reserve transaction space. A second writer can complete a copy-on-write during that gap and remap the cloned file to a new block. When the first writer reacquires the lock it refreshes the copy-on-write fork but continues using the old data-fork mapping; the upstream patch summary captures the failure succinctly: "the mappings are stale as soon as we reacquire the ILOCK."
Because the write uses direct I/O and therefore skips the page cache, it lands straight to disk. XFS sees the block as unshared and allows the write, so data intended for the attacker’s clone is written into the protected file. The patch touches xfs_reflink_fill_cow_hole() and xfs_reflink_fill_delalloc(); both now snapshot ip->i_df.if_seq before dropping the lock and re-read the data fork with xfs_bmapi_read() if the counter moved. In testing the race usually won in under ten seconds, and Qualys' published demo removed the root password on a default RHEL 10.2 box.
Who is exposed and how to check your systems
- Three conditions are required for exploitation:
- The system runs Linux 4.11 or later without the RefluXFS fix.
- The XFS filesystem was created with reflink=1.
- The readable target file and an attacker-writable directory are on the same XFS filesystem.
- Qualys listed default installations that can meet those conditions: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux and CloudLinux 8, 9 and 10, Fedora Server 31 and later, Amazon Linux 2023, and Amazon Linux 2 images from December 2022 onward. RHEL 7 filesystems are not affected because they predate XFS reflink support.
- Debian, Ubuntu, SLES, and openSUSE do not generally use XFS for the root filesystem by default; they are exposed only if an administrator chose XFS with reflink enabled at install time.
To check a mounted volume, run: xfs_info / | grep reflink= — a result of reflink=1 means the filesystem meets condition two. Repeat on any other mounted XFS volumes where a protected file and an attacker-writable directory might share the filesystem.
Vendor response: patches, advisories, and the reboot requirement
The upstream fix was merged July 16, and Linux vendors have been shipping backported kernels since then. Red Hat issued Important-rated kernel advisories across affected RHEL 8, 9, and 10 streams, with errata beginning to land on July 14 — eight days before the coordinated disclosure — named RHSA-2026:39179 and RHSA-2026:39180 for RHEL 8 and RHSA-2026:39494 for RHEL 10; extended-support and SAP streams followed through July 17. The vendor bug tracker entry was auto-imported on July 10 under the title "kernel: XFS data corruption using reflink."
Installing an updated package does not replace the kernel already running in memory. The guidance is straightforward: apply the vendor update, reboot the system, and verify the host is running the fixed kernel. Confirm the advisory is applicable to the exact release — coverage is stream-specific, and anyone who applied the errata on schedule was covered before RefluXFS had a public name.
How Qualys discovered RefluXFS and the state of public proof-of-concept
Qualys says an AI model — Claude Mythos Preview, Anthropic's restricted-access frontier model — was used to locate the race: the model was asked to find a vulnerability similar to Dirty COW, identified the race, wrote a working root exploit, and drafted the advisory. Researchers then reproduced the exploit on a stock Fedora Server 44 install, validated the model's reasoning, and coordinated disclosure upstream. Qualys published no standalone exploit code; Red Hat's tracker logged a public proof-of-concept on July 22 that points to the advisory posted to the oss-security list, which details the race and exploitation steps. As of the time of reporting, none of the vendors tracking the flaw had reported exploitation in the wild.
What this means for system administrators and cloud operators
Patch exposed and multi-tenant systems first — Qualys explicitly recommends prioritizing any reflink-enabled XFS host where untrusted code can run locally, whether via a shell, a CI job, or a compromised service. There is no mount option or sysctl to disable XFS reflinks after creation, and Qualys reported no practical mitigation or temporary configuration to prevent exploitation; SELinux Enforcing, seccomp, kernel lockdown, and container boundaries did not stop the attack in testing. The actionable sequence is clear: confirm reflink=1 where applicable, apply vendor kernel updates, reboot, and verify the new kernel is active.
