On July 22, the vulnerability CVE-2026-64600 (RefluXFS) in the Linux kernel was disclosed: a race condition in the XFS reflink subsystem allows an unprivileged local user to overwrite root-owned files and gain persistent privileged access. The bug has existed in kernels since version 4.11 (2017). According to Qualys researchers, exploitation conditions are met on default installations of Red Hat Enterprise Linux and derivative distributions, Fedora Server, and Amazon Linux. The fix was merged into the mainline kernel on July 16, and vendors have begun releasing updated kernels. A public PoC exploit is available, but exploitation in the wild had not been observed at the time of disclosure. The only effective measure is to update the kernel and then reboot.
Vulnerability mechanism
The vulnerability belongs to the TOCTOU (time-of-check-to-time-of-use) class — a check-then-use bug via a locking cycle. The attacker clones a root-owned file into their own working file using the FICLONE system call, which only requires read permission on the source file. The XFS reflink mechanism uses copy-on-write: initially, both files reference the same physical disk blocks.
The kernel reads the data-fork mapping under the inode lock and passes it to the xfs_reflink_fill_cow_hole() function, which releases this lock to reserve transaction space. During this window, a second parallel writer can complete the copy-on-write operation and remap the cloned file to a new block. When the first writer re-acquires the lock, it updates the COW fork but continues to use the stale block address from the data fork.
As described in the patch: “the mappings become stale as soon as we re-acquire the ILOCK.” The stale address now points to a block that exclusively belongs to the original protected file. XFS considers the block unshared and allows a direct write — the data intended for the attacker’s clone end up in the root-owned target file.
Critically, Direct I/O writes bypass the page cache and the target inode entirely, so the file’s metadata — owner, permissions, timestamps, setuid bit — remain untouched. According to the researchers, a modified setuid-root binary continues to execute with root privileges. Tests did not reveal any kernel warnings or log entries. On the test machine, the race was reportedly won in less than ten seconds.
The patch affects two functions — xfs_reflink_fill_cow_hole() and xfs_reflink_fill_delalloc(). The fix stores the value of the ip->i_df.if_seq counter before releasing the lock and re-reads the data fork via xfs_bmapi_read() if the counter has changed.
Who is at risk
Exploitation requires that three conditions be met simultaneously:
- The system is running Linux kernel 4.11 or newer without the RefluXFS fix.
- The XFS filesystem was created with the
reflink=1option. - The target file (readable) and a directory writable by the attacker are located on the same XFS filesystem.
According to Qualys, default installations of the following systems may meet these conditions:
- RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux versions 8, 9, and 10
- Fedora Server 31 and newer
- Amazon Linux 2023 and Amazon Linux 2 images starting from December 2022
RHEL 7 is not affected — its filesystems predate XFS reflink support. The Debian, Ubuntu, SLES, and openSUSE distributions do not use XFS for the root filesystem by default and are only exposed if XFS with reflink enabled was explicitly chosen during installation.
To check, run:
xfs_info / | grep reflink=
A result of reflink=1 means the second exploitation condition is met. The same check should be performed for all mounted XFS volumes where protected files and writable directories may coexist.
No workarounds
Qualys reports that no practical temporary mitigations exist. There is no mount option or sysctl parameter that would disable reflink on an already created filesystem. In the researchers’ tests, SELinux in Enforcing mode, seccomp, kernel lockdown, and container boundaries did not stop exploitation. Memory protection mechanisms (KASLR, SMEP) are not applicable: this is a block-device-level write, not memory corruption.
The only limitation is that the race triggers only if the target file’s block is unshared. However, as noted in the advisory, an unprivileged user can clear this condition, for example by running chsh, and setuid-root binaries in typical configurations are not reflink copies in the first place.
The role of AI in discovery
Qualys states that the vulnerability was discovered using an AI model — Claude Mythos Preview from Anthropic — which was tasked with finding a vulnerability similar to Dirty COW. According to the company, the model pinpointed the race, wrote a working exploit to gain root, and drafted the advisory. The researchers then reproduced the bug on a default Fedora Server 44 installation, verified the model’s logic, and coordinated disclosure with kernel developers. This claim comes solely from Qualys and has not been independently confirmed.
Patch status
Red Hat has issued advisories with an Important rating for the affected RHEL 8, 9, and 10 streams. Errata began to appear on July 14 — eight days before coordinated disclosure: RHSA-2026:39179 and RHSA-2026:39180 for RHEL 8, RHSA-2026:39494 for RHEL 10, with additional updates for extended support and SAP streams up to July 17. Coverage depends on the specific stream — you must verify that an erratum exists for your exact release.
The entry in the Red Hat bug tracker was automatically imported on July 10 under the title “kernel: XFS data corruption using reflink” and initially described the issue as potential data corruption. The public PoC was recorded in the tracker on July 22.
According to the Debian security tracker as of July 23, the fix is available in trixie-security (kernel 6.12.96-1) and in unstable (7.1.4-1). The base trixie kernel (6.12.94-1), forky (7.1.3-1), as well as bookworm and bullseye, including their security branches, are still marked as vulnerable.
Recommendations
- Prioritize multi-user systems and hosts where untrusted code can run locally (CI/CD, shared servers, compromised services).
- Install the updated kernel from your vendor. Organizations that applied Red Hat errata before July 22 are already protected.
- Reboot the system after installing the package — the update does not replace the kernel already running in memory.
- Verify that the system has booted into the fixed kernel:
uname -r. - Check all XFS volumes for
reflink=1, not just the root filesystem.
RefluXFS is a vulnerability with no workarounds: neither SELinux, nor containerization, nor seccomp blocks exploitation. With a public PoC and detailed attack steps published on the oss-security mailing list, the window for safely doing nothing is minimal. The only reliable action is to install an updated kernel and reboot every host with XFS reflink, confirming with uname -r that the system is running a fixed version.
