RefluXFS (CVE-2026-64600): am I actually vulnerable?

On 22 July, Qualys disclosed RefluXFS — CVE-2026-64600 — a local privilege escalation in the Linux kernel’s XFS filesystem. An unprivileged user can overwrite a root-owned file and walk away with persistent root. It’s a race in the copy-on-write path: two concurrent O_DIRECT writes to the same reflinked file, the inode lock gets dropped while one writer waits for log space, and the other slips in and remaps the block underneath it. The kernel then trusts a stale block address and writes to storage it no longer owns. The bug has been sitting in the tree since Linux 4.11, back in 2017, and it needs — in Qualys’ own words — “no special capabilities or non-default configurations.”

Which is exactly why the first reaction in every ops channel this week was the same three words: “do we have XFS?” Good instinct. But if you stop there, you’ll either scare yourself over a box that isn’t reachable, or wave off one that is. Let’s work the question the way we work it inside KernelScan.

1. Do I even have XFS — and which symbol is it?

The kernel gate is a single Kconfig symbol:

# In your kernel .config (or /boot/config-$(uname -r)) CONFIG_XFS_FS=y # XFS compiled into the kernel image CONFIG_XFS_FS=m # XFS built as a loadable module (xfs.ko) # CONFIG_XFS_FS is not set # XFS not built at all; RefluXFS cannot exist here

The neighbours you’ll see next to it — CONFIG_XFS_QUOTA, CONFIG_XFS_RT, CONFIG_XFS_ONLINE_SCRUB, CONFIG_XFS_POSIX_ACL — are all sub-features. None of them gate this bug. Reflink, importantly, is not a kernel build option at all. There is no CONFIG_XFS_REFLINK to switch off. Reflink is an on-disk feature turned on when the filesystem is created (mkfs.xfs, superblock flag reflink=1) — and it has been the mkfs.xfs default since 2019. RHEL 8 and 9 ship reflinked XFS out of the box. So on a modern distro you can’t “turn reflink off” to dodge this; the config-level answer is binary: CONFIG_XFS_FS present, or not.

2. “…but what if someone plugs in an XFS USB stick?”

This is the question that separates people who think about kernels from people who just read CVE feeds. Let’s take it seriously, step by step.

Does the module even load? Yes. XFS registers a module alias (fs-xfs). The moment userspace calls mount() with type xfs, the kernel fires request_module("fs-xfs") and modprobe pulls in xfs.ko on demand. So even a kernel with CONFIG_XFS_FS=m and XFS “not loaded” will happily autoload it the first time an XFS volume is mounted. On a desktop distro, inserting a stick is enough: udisks2 / the desktop auto-mounts it, which triggers the autoload and the parse. So the module-autoload half of the instinct is correct.

Does that make me vulnerable to RefluXFS? No. And this is the part the headlines skip. RefluXFS is a privilege-boundary bug. To exploit it you need a reflink XFS volume that holds both a target you don’t own (a root-owned config file or a SUID-root binary) and a directory you can write to. A USB stick you just inserted fails that test: you own everything on your own stick, so there’s no boundary to cross. The real RefluXFS target is the volume you already share with root — the root filesystem, /var/tmp, a shared data mount — reached from a shell you already have. Removable media is a red herring for this CVE.

So “am I affected?” isn’t one question — it forks by threat model, and the config symbol is the same on both branches:

	RefluXFS — CVE-2026-64600	Malformed-image class — e.g. CVE-2026-64187
Bug	reflink CoW race → overwrite root-owned file → local root	log-recovery parse bug → kernel crash / DoS at mount
Attacker needs	a local shell, and a reflink XFS volume shared with root that has an attacker-writable directory	to get the system to mount a crafted XFS image
USB stick helps?	No — you own your own stick	Yes — if you auto-mount removable media
Config gate	CONFIG_XFS_FS	CONFIG_XFS_FS
Real discriminator	untrusted local users on a shared XFS volume	do you auto-mount untrusted media?

Now the practical payoff. A sealed, headless appliance — one image, no interactive local users, and udev configured never to auto-mount removable storage — ships CONFIG_XFS_FS=y and is still not practically reachable for either bug. Same symbol, opposite verdict from a multi-tenant RHEL host where analysts hold shell accounts on an XFS home server. This is precisely the kind of thing a VEX statement should say out loud: affected code present, not reachable in this product’s configuration — rather than a red “CONFIG_XFS_FS=y, you’re vulnerable” that a naïve config grep would emit.

3. The history NVD won’t tell you for two more weeks

The other half of “am I affected?” is when. Kernel CVEs have a life before the number is minted, and a scary blind spot after. Here’s RefluXFS end to end:

Date	Milestone	Where you’d see it
Feb 2017	Bug introduced in the Linux 4.11 merge window — commit 3c68d44a2b49 (“xfs: allocate direct I/O COW blocks in iomap_begin”); 4.11 shipped that April	Nowhere — silent for 9 years
07 Jul 2026	Reported privately to XFS maintainers + kernel security team, with PoC	Nowhere (embargo)
14 Jul 2026	Fix committed to the XFS development tree	linux-xfs list / git
15 Jul 2026	Heads-up sent to the linux-distros list	Private distro channel
16 Jul 2026	Fix merged to mainline — commit 2f4acd0, “xfs: resample the data fork mapping after cycling ILOCK”	Torvalds’ tree — no CVE, no “security” label
18 Jul 2026	Backport ships in the actively-maintained trees — 6.12.96, 6.18.39, 7.1.4 — four days before the CVE is public	Public stable releases
22 Jul 2026 16:00 UTC	Coordinated public disclosure; “RefluXFS”, CVE-2026-64600	Qualys advisory, oss-security
23 Jul 2026	Record lands in NVD — status “Received” (no CVSS, no CWE)	Your scanner… sort of
24 Jul 2026	Backport reaches the long-term trees — 6.6.145, 6.1.178, 5.15.212	Public stable releases

Was the risk visible on 16 July — six days before the CVE existed?

Almost certainly, to anyone who was watching. The fix landed in mainline on 16 July as an ordinary commit: no CVE number, no “security” in the subject, just “xfs: resample the data fork mapping after cycling ILOCK.” That’s a textbook silent fix — and it is not hard to read. To anyone fluent in XFS, “we re-checked a reference count using a stale mapping captured before we dropped the lock” describes a write-to-the-wrong-block data-integrity bug in as many words, which is to say a weaponisable one. It gets worse: the patch was signed by the XFS maintainer himself, its Fixes: tag points straight at the 2017 commit that introduced it (3c68d44a2b49), and it carries Cc: stable@vger.kernel.org # v4.11 — the commit announcing, in its own trailers, that it needs backporting to every kernel released since 2017. And it didn’t stay theoretical for long: by 18 July the fix was shipping in public stable releases (6.12.96 and friends), four days before the coordinated disclosure. So for the better part of a week the bug was public in the source tree and in shipped kernels, yet invisible in every CVE feed — the classic patch-gap. A defender who only reacts to CVE numbers had no signal at all; a defender diffing the tree could have started assessing exposure the day it merged. That asymmetry is the argument for watching the tree, not the feed.

Where’s the stable fix now? Out everywhere — but on a staggered clock

Here’s the part the CVE record quietly flattens. As of today the fix is in a released point release on every maintained tree — but the branches did not land together, and which one you’re on decided how long you waited. The actively-developed trees took it first: 6.12.96, 6.18.39 and 7.1.4 on 18 July — two days after mainline, and before the CVE was even public. The long-term trees that most enterprises and appliances actually run came last, in today’s 24 July batch: 6.6.145, 6.1.178 and 5.15.212 — eight days after mainline and two days after disclosure. The kernel CNA record lists all of them as “fixed,” but each names a different release, and “fixed in 6.1.x” is only true from 6.1.178 onward — 6.1.177 and earlier are still vulnerable. So don’t reason from the branch family; pin the exact point release you run. And the distro trees are their own clock again: RHEL, Ubuntu and SUSE ship heavily-backported kernels (RHEL’s is a 5.14-era tree, patched as 5.14.0-687.26.1.el9_8 and friends), each on its own schedule.

Who waited longest — and why it isn’t neglect

Notice the ordering: the trees that got the fix first were the current ones; the trees that waited until 24 July were the long-term ones — 5.15, 6.1 and 6.6 — which is exactly what embedded and appliance builders pin to. And the people building on those trees are the least likely to have heard early: the big distributions sit on the linux-distros list and got the private heads-up on 15 July, a day before mainline; the router, NAS and gateway vendors pulling Greg’s stable releases are not on that list and got no advance notice at all. So for a product on 5.15/6.1/6.6, the window with a fix in mainline but not in their stable release ran from 16 to 24 July — about a week — and it closed only today.

It’s tempting to read that ordering as the maintainers leaving embedded out in the cold. It isn’t. Look at what RefluXFS needs: a reflink XFS volume and untrusted local users sharing it. Then look at what embedded actually runs. The dominant root filesystems in that world are ext4, SquashFS, UBIFS, JFFS2 and f2fs; XFS is comparatively rare on an appliance, and a device that hands out multiple interactive shell accounts is rarer still. For the overwhelming majority of LTS-based products the vulnerable path simply isn’t reachable — so backporting to those trees a few days behind the current ones is sensible triage, not neglect. The stable queue is quietly encoding the same reachability judgment this whole post keeps circling back to.

The Dependency-Track gap — this is the one that bites

Here’s the trap that outlives the backport. As of 23 July, the NVD record for RefluXFS is published but marked “Received.” The kernel CNA’s data is in — including the affected/fixed version ranges — but NVD has not assigned a CVSS score, a severity, or a CWE yet. NVD’s own analysis (and the CPE product identifiers it attaches) can lag the publish date by days to weeks.

The information you actually need to make the call — which kernel versions are affected, which contain the fix, and whether the vulnerable code is even reachable in your config — exists from day one. It’s in the kernel CNA record and in the source tree. It just isn’t in the CVSS-score-shaped field your scanner sorts on. That two-week hole between “disclosed” and “NVD-analyzed” is exactly the window an attacker with a working PoC is happiest about.

The 30-second version

For RefluXFS specifically, walk these three and you have your answer:

1. Is CONFIG_XFS_FS in your kernel? If not set, you’re done — not affected. If =y or =m, the code is present; keep going.
2. Do untrusted local users share a reflink XFS volume with root? If yes (multi-user host, shared XFS home/data, containers on an XFS backing store) — reachable; move to the exact fixed release for your branch (e.g. 6.1.178, 5.15.212). If it’s a sealed appliance with no interactive local users — code present, not reachable.
3. Separately: do you auto-mount removable media? That doesn’t expose RefluXFS, but it does expose the malformed-image XFS bugs (like CVE-2026-64187). If your product ingests untrusted disks or USB, treat “XFS is present” as an attack surface in its own right.

“Do we have XFS?” gets you to the config symbol. Everything that decides whether you actually ship the vulnerability — who can reach it, on which volume, through which door, and on which of your kernel branches it’s already fixed — lives past that first grep. That reasoning is what KernelScan does for every kernel CVE the day it drops, config-aware and backport-aware, without waiting on an NVD score. Upload a .config and it’ll tell you not just whether the code is there, but whether it’s a door anyone can open.