After a run of bugs that only wrote to memory, along comes RefluXFS, and this one leaves a mark on disk. It is a local privilege escalation flaw in the Linux kernel, tracked as CVE-2026-64600 with a CVSS score of 7.8. An ordinary, unprivileged user can use it to overwrite the contents of any readable file on an XFS volume and, as a result, gain root. Worse, it has been sitting in the kernel since 2017, and classic hardening does nothing against it. The bug was found by the Qualys Threat Research Unit and disclosed on July 22nd.

Where the Name and the Bug Come From

The name is a pun: reflink plus XFS. Reflink is XFS’s copy-on-write feature that lets two files share the same physical blocks on disk until one of them is modified. Only on a write does the kernel make a copy, allocate a new private block, and point the file at it. This is standard on RHEL 8 and later, where reflink=1 is set by default.

The problem is a race condition on exactly that copy-on-write path. When the kernel needs to allocate a transaction in the XFS log, it briefly drops the inode lock (ILOCK) and waits for log space. After re-acquiring it, it makes a mistake: it checks the block’s reference count using the old, stale address instead of re-reading the file’s current mapping. In that short window, everything can change.

How the Attack Works

The race is set up with two concurrent O_DIRECT writes to the same shared block:

  1. File A shares physical block P with another file (refcount = 2).
  2. The attacker issues two concurrent O_DIRECT writes to the same offset in file A.
  3. The first writer enters copy-on-write and, to allocate a transaction, drops ILOCK.
  4. In that window the second writer finishes a full CoW cycle: it remaps A to a new block and drops P’s reference count to one.
  5. The first writer re-acquires the lock, checks the reference count at the old address P, sees one, and concludes the block is private.
  6. It writes with O_DIRECT straight into block P, bypassing the page cache. But P still backs the original file, so the attacker’s data lands on disk, inside someone else’s file.

With a “overwrite any readable file” primitive, escalation is simple: just replace something root will run with full privileges anyway, for example a cron script, an executable, or a config file. From that point on, you have root.

Why It Is So Dangerous

Several things add up to a nasty profile:

  • The write goes to disk, not to memory. O_DIRECT bypasses the page cache, so the change is permanent and survives a reboot. That is the opposite of the recent DirtyClone family, where the modification lived only in the page cache.
  • No exotic requirements. No user namespaces, no extra capabilities, no non-default configuration. All it takes is a local account, an XFS volume with reflink, and a writable directory next to a readable target.
  • Hardening does not help. KASLR, SMEP, SMAP, kernel lockdown, seccomp profiles, container boundaries, none of it blocks this path. The flaw also works under SELinux in Enforcing mode.
  • Silence in the logs. Exploitation leaves no kernel log entries.

The one upside for a defender is that since the change lands on disk, file-integrity tools (AIDE, Tripwire, checksums) will notice it after the fact. A pity that it is after the fact.

Who Is Affected

Just about anyone keeping data on XFS with reflink enabled, which is the default across the Red Hat family: RHEL 8/9/10, CentOS Stream, Oracle Linux, Rocky, AlmaLinux, CloudLinux, Amazon Linux 2023, Fedora. Qualys estimates over 16 million vulnerable systems. Multi-tenant machines are especially exposed: servers with many accounts, container hosts, CI environments.

How to Defend

Most important: update the kernel and reboot. The fix landed in mainline on July 16th (commit 2f4acd0, “xfs: resample the data fork mapping after cycling ILOCK”). The patch does exactly what was missing: after re-acquiring ILOCK it re-samples the file’s mapping instead of trusting the old block address. Distributions shipped patched kernels the same day as disclosure.

Mitigations are worse than usual, because there essentially are none:

  • Disabling reflink only works when creating the filesystem (mkfs.xfs -m reflink=0). You cannot flip it on an existing volume on the fly, so for running machines it is not an option.
  • Red Hat published a stopgap SystemTap script, but that is a temporary workaround, it needs manual deployment and does not survive a reboot.

In short: you cannot configure around this flaw or isolate it. The real fix is a fresh kernel and a reboot.

Timeline

  • 2017 (Linux 4.11, commit 3c68d44a2b49): the bug enters the kernel along with reflink support
  • July 16, 2026: fix merged into mainline (commit 2f4acd0)
  • July 22, 2026: public disclosure (Qualys, oss-security) and distribution errata

A Curious Detail

RefluXFS is unusual in that Qualys found it with the help of an AI model, given a specific task: hunt the kernel for a bug in the style of the classic Dirty COW. The result is this XFS race. However it was found, the fix is an ordinary, classic patch to the locking logic.

Takeaway

RefluXFS is a reminder that sharing blocks between files is a powerful feature, but every moment the kernel briefly lets go of a lock is a potential window for a race. One skipped re-validation of the mapping was enough to turn two innocent writes into an overwrite of someone else’s file on disk. If you keep data on XFS in a multi-tenant environment, treat this as a priority: update the kernel and reboot, because here there is no shortcut.

Sources: Qualys Threat Research, Qualys Advisory, oss-security, Red Hat, The Hacker News