RefluXFS, a new Linux kernel flaw disclosed on July 22 and tracked as CVE-2026-64600, lets an unprivileged local user overwrite root-owned files on an XFS filesystem and gain persistent root access.
Qualys said default installations of Red Hat Enterprise Linux and its derivatives, Fedora Server, and Amazon Linux can meet the conditions for exploitation.
The company demonstrated the race against /etc/passwd and setuid-root binaries. The overwrite lands at the block layer. It survives a reboot and leaves the target’s ownership, permissions, timestamps, and setuid bit untouched, so a modified setuid-root binary still runs as root.
The fix was merged on July 16, and Linux vendors have begun shipping backported kernels. The patch traces the bug to Linux 4.11 in 2017: a Fixes: tag naming commit 3c68d44a2b49 and a stable backport request marked # v4.11.
Who is exposed
Exploitation requires three conditions:
- The system runs Linux 4.11 or later without the RefluXFS fix.
- The XFS filesystem was created with
reflink=1. - The readable target and an attacker-writable directory are on the same XFS filesystem.
Qualys said to patch exposed and multi-tenant systems first, which means any reflink-enabled XFS host where untrusted code can run locally, whether through a shell, a CI job, or a compromised service.
The advisory lists the 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.
Check the root filesystem:
xfs_info / | grep reflink=
reflink=1 means condition two is met. Run the same check on any other mounted XFS volume where a protected file and an attacker-writable directory share the filesystem.
The Stale Mapping
An attacker clones a root-owned file into a scratch file with FICLONE, which needs only read access on the source, then races concurrent O_DIRECT writes against the clone. XFS reflinks use copy-on-write, so both files initially reference the same physical disk blocks.
The kernel reads the data-fork mapping under the inode lock and hands it to xfs_reflink_fill_cow_hole(), which cycles that lock to reserve transaction space.
A second writer can complete the copy-on-write operation 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 describes the failure plainly: “the mappings are stale as soon as we reacquire the ILOCK.”
That stale address now points to a block owned only by the original protected file. XFS sees the block as unshared and permits the direct write, so data intended for the attacker’s clone lands in the target instead.
It is a check-then-use error across a lock cycle. The shared-status query itself is correct; what it queries is a block address captured before the lock was released.
The Hacker News found the patch touches two helpers, xfs_reflink_fill_cow_hole() and xfs_reflink_fill_delalloc(). The second carries the same lock-cycle pattern and does not appear in the Qualys advisory. In both, the fix snapshots ip->i_df.if_seq before the lock is dropped and re-reads the data fork with xfs_bmapi_read() if the counter moved.
Direct I/O skips the page cache and has no revalidation hook, so the write lands on disk. Because it bypasses the target inode entirely, the metadata never changes, and the researchers said their tests produced no kernel warning or log entry.
On the test machine, the race usually won in under ten seconds. The published demo strips the root password on a default RHEL 10.2 box.
Qualys said an AI model found the flaw. The company pointed Claude Mythos Preview, Anthropic’s restricted-access frontier model, at the kernel and, per its technical advisory, “asked it to find a vulnerability similar to Dirty COW.”
The model located the race, wrote a working root exploit, and drafted the advisory. Researchers then reproduced it on a stock Fedora Server 44 install, checked the model’s reasoning, and coordinated disclosure upstream.
It is not the team’s first aged kernel bug this year. Qualys has been finding a lot of these. A day earlier, it disclosed a snap-confine flaw in Ubuntu Desktop, CVE-2026-8933, where two races let a local user get root on default installs. In May it found a nine-year-old bug in the kernel’s ptrace checks.
Patch, Then Reboot
Red Hat has issued Important-rated kernel advisories across affected RHEL 8, 9, and 10 streams. The errata began landing on July 14, eight days before the coordinated disclosure: RHSA-2026:39179 and RHSA-2026:39180 for RHEL 8 and RHSA-2026:39494 for RHEL 10, with extended-support and SAP streams following through July 17.
Coverage is stream-specific, so confirm an advisory exists for your exact release. Anyone who applied those errata on schedule was covered before RefluXFS had a name. Check your patch dates before assuming exposure.
The vendor’s bug tracker files the flaw under the title “kernel: XFS data corruption using reflink.” The entry was auto-imported on July 10 and initially described the issue as possible data corruption from reflinking a file.
As of July 23, Debian’s tracker listed the fix in trixie-security as kernel 6.12.96-1 and in unstable as 7.1.4-1. Trixie’s base kernel 6.12.94-1 and forky’s 7.1.3-1 were still marked vulnerable, as were bookworm and bullseye, including their security branches.
There is no mount option or sysctl that disables XFS reflinks after a filesystem has been created, and Qualys said no practical mitigation or temporary configuration change is available. SELinux in Enforcing mode, seccomp, kernel lockdown, and container boundaries all failed to stop it in the company’s testing. Memory protections like KASLR and SMEP never applied: this is a block-layer write, not memory corruption.
One apparent limit is not one. The race only fires if the target’s block starts unshared, so a file an administrator already reflink-copied cannot be hit. The advisory says an unprivileged user can reset that condition by running chsh, and that setuid-root binaries are unlikely to have been reflinked in the first place.
Qualys published no standalone exploit code. Red Hat’s tracker logged a public proof-of-concept on July 22, pointing at the advisory posted to the oss-security list, which sets out the race and the exploitation steps in full. None of the vendors tracking the flaw had reported exploitation in the wild at the time of writing.
The Hacker News has reached out to Red Hat for comment on its assessment of the flaw’s impact and to Qualys for further detail on the finding, and will update this story with any response.
Installing the package does not replace the kernel already running in memory. Apply the vendor update, reboot the system, and verify that it is running the fixed kernel.
