www.it-connect.fr
RefluXFS: XFS Flaw Gives Root Access on RHEL, CentOS, and AlmaLinux
RefluXFS is the name of a security flaw hidden since February 2017 in the Linux kernel's XFS file system. It allows a simple local user to overwrite a file owned by root directly on disk, without leaving any trace in kernel logs. Here's what we know about this flaw uncovered with the help of Claude Mythos Preview, Anthropic's AI model.
Let's start with an important clarification: the RefluXFS flaw was discovered as part of the Glasswing project, in which Qualys and Anthropic are jointly involved. The researchers therefore had access to Claude Mythos Preview to carry out this vulnerability research. "As part of this research, we tasked Claude Mythos Preview with looking for a Dirty COW-style race condition in the Linux kernel, progressively refining our prompts to focus its searches on race conditions within memory management and file system directory modules," the researchers explained.
Table of Contents
The essentials about the RefluXFS flaw: CVE-2026-64600
On July 22, 2026, Qualys's research team published a report on a race condition located in the copy-on-write path of the XFS file system. A local unprivileged user can exploit it to overwrite, on disk, any file they are able to read. From there to becoming root is only a short step, and Qualys crossed it with a working exploit.
It all starts with reflink, XFS's copy-on-write cloning feature. When you clone a file with cp --reflink, no data is copied: both files point to the same physical blocks. And that's where everything happens, because cloning only requires read permission, not write permission. A standard user can therefore clone /etc/passwd or the /usr/bin/su binary, which they can read but not rewrite, and obtain a personal copy that shares the same disk blocks as the protected original. The only constraint: stay on the same file system.
The problem occurs immediately afterward. During an O_DIRECT write on the cloned file, the kernel briefly releases its inode lock, then checks whether the block is still shared, but does so from an address captured before the lock was released. If a concurrent write slipped in during that window, the check returns stale information: the write believes it is on private ground and goes straight into the block that still holds the original file.
The result is hard to detect. The modification is written at the block level, survives a reboot, and leaves no trace in kernel logs. Because the target inode is never touched, owner, permissions, timestamps, and the SUID bit remain unchanged: a modified SUID root binary continues to run as root. In Qualys's demonstration, the exploit rewrites /etc/passwd with a single edit, removing the x from root's password field, and the su command then opens a root shell without asking for anything. On the test machine (a default Fedora Server 44), the vulnerability is exploited in a few seconds...
Who is affected?
Three conditions must be met at the same time for this vulnerability to be exploitable on a machine:
- A Linux kernel version 4.11 (April 2017) or later without the patch, meaning almost all currently maintained kernels.
- An XFS file system with
reflink=1in its superblock. - An interesting target file (a root-owned configuration file or a root
SUIDbinary) coexisting with a directory writable by an unprivileged user.
That last condition is met by every default single-volume installation, Qualys notes. Indeed, the /var/tmp directory is writable by all users and is on the same partition as /etc and /usr/bin. To check the second point, one command is enough: xfs_info / | grep reflink=. If the output shows reflink=1, you are exposed.
In practice, several Linux distributions are vulnerable in their default configuration: Red Hat Enterprise Linux 8, 9 and 10 and CentOS Stream, Rocky Linux, AlmaLinux and CloudLinux (versions 8, 9 and 10), Oracle Linux 8, 9 and 10, Fedora Server начиная from version 31, as well as Amazon Linux 2023 and Amazon Linux 2 AMIs since December 2022. That's a lot of distributions, and therefore millions of potentially vulnerable machines. For its part, Qualys estimates that about 16.4 million machines could be affected.
As for other popular distributions, such as Debian, Ubuntu, Fedora Workstation, openSUSE and Arch Linux, they do not use XFS for the default root file system and are therefore not affected (unless explicitly chosen). "Distributions whose default installer does not use XFS for the root file system (Debian, Ubuntu, Fedora Workstation, SLES, openSUSE, Arch) cannot be exploited in their default configuration," the researchers said.
"I enabled SELinux in Enforcing mode, so I'm protected." That's perhaps what some of you may think. Well, no. Qualys states exactly the opposite. None of the usual protections can shield against this flaw. The researchers' report explains that neither SELinux in Enforcing mode, nor kernel lockdown, nor container isolation, nor the KASLR, SMEP and SMAP memory protections block the attack, because the flaw operates at the file system allocation layer.
How can you protect yourself?
A Red Hat engineer, Marco Benatto, shared on the oss-security mailing list a SystemTap script that neutralizes XFS's reflink entry point (the xfs_file_remap_range function) by forcing the operation to return an error. The Red Hat product team has also adopted this method as a valid mitigation, but be careful, because this workaround breaks reflink cloning for applications that depend on it. It is therefore more of an emergency measure than a long-term fix.
The only real way to protect yourself is to patch. And the fix for this vulnerability was merged into the Linux kernel on July 16 via commit 2f4acd0. For the RHEL family and its derivatives, the target versions are 4.18.0-553.144.1.el8_10 for branch 8.10, 5.14.0-687.26.1.el9_8 for 9.8 and 6.12.0-211.34.1.el10_2 for 10.2. The patches are now available, which is good news.
As of this writing, no in-the-wild exploitation of the RefluXFS flaw has been reported. The Qualys report is available on this page.
