Dateline: July 23, 2026
16 Million Linux Systems, One Race Condition, Zero Log Entries
Over 16.4 million systems may be sitting on it. A flaw that has been in the Linux kernel since 2017 was disclosed on July 22, and it lets a person with a plain user account rewrite files that only root should touch. No exotic setup. No admin rights. Just a normal login on a normal server.
What Happened?
Researchers at the Qualys Threat Research Unit disclosed CVE-2026-64600, nicknamed RefluXFS. It is a race condition in the XFS filesystem copy on write path.
Here is the short version. XFS reflinks let two files share the same physical blocks on disk. When someone writes to a shared block, the kernel copies it to a new private block first. To avoid a deadlock while waiting for log space, the kernel briefly lets go of its inode lock.
That pause is the whole bug. A second writer can slip in during the gap and remap the file. When the first writer comes back, it checks the block using an address it captured before the pause. The block now looks private, so the write goes through, straight into the protected file.
Because the write uses O_DIRECT, it skips the page cache and lands on disk. The target file keeps its owner, its permissions, its timestamps, and its setuid bit. Nothing in the kernel log records it. The change survives a reboot.
The published demo strips the root password off a default RHEL 10.2 box. On the test machine the race usually won in under ten seconds.
One more detail worth noting. The flaw was found by pointing an AI model at the kernel and asking it to hunt for something similar to Dirty COW. The model found the race, wrote a working exploit, and drafted the first version of the advisory. Human researchers then reproduced it and checked every claim before disclosure.
What’s the Impact?
Three things have to be true for a system to be exposed. The kernel is 4.11 or later without the fix. The XFS filesystem was made with reflink=1. And a readable target file plus a user writable directory live on that same filesystem.
Default installs of RHEL 8, 9, and 10 meet those conditions. So do CentOS Stream, Oracle Linux, Rocky, AlmaLinux, CloudLinux 8 through 10, Fedora Server 31 and later, Amazon Linux 2023, and Amazon Linux 2 images from December 2022 onward. RHEL 7 is safe because it predates reflink support. Debian, Ubuntu, and SUSE only qualify if an admin picked XFS with reflink at install time.
The hardening you already run does not help here. SELinux in Enforcing mode failed in testing. So did seccomp, kernel lockdown, and container boundaries. Memory protections like KASLR and SMEP never applied because this is a block layer write, not memory corruption. There is no mount option or sysctl that turns reflink off after a filesystem exists.
The real damage shows up in shared environments. Multi tenant hosts, CI runners, and any box where untrusted code gets a shell. One low value account becomes root, quietly, with persistence that outlives a reboot.
How to Avoid This
- Run xfs_info / | grep reflink= on your root filesystem. If it returns reflink=1, condition two is met.
- Check every other mounted XFS volume too.
- Apply your vendor kernel update, then reboot.
- Installing the package does not swap out the kernel already running in memory, so a reboot is not optional here.
- Confirm the machine came back on the fixed kernel.
- Red Hat shipped Important rated advisories across RHEL 8, 9, and 10 streams starting July 14, eight days before disclosure. Anyone patching on schedule was already covered.
- Coverage is stream specific, so confirm an advisory exists for your exact release before you assume anything.
- Debian’s tracker listed the fix in trixie-security and unstable as of July 23. Bookworm and bullseye were still marked vulnerable.
