SKELETONKEY/modules/refluxfs_cve_2026_64600/MODULE.md

refluxfs — CVE-2026-64600

"RefluXFS" — a time-of-check/time-of-use race in the XFS reflink copy-on-write path that lets any unprivileged local user overwrite the on-disk contents of any file they can read, on any XFS volume mounted with reflink=1 that they can write to. No user namespace, no capability, no crafted filesystem image, no kernel offsets. It has been present since reflink direct-I/O CoW landed in 4.11 (2017) — a nine-year window.

This is the corpus's first XFS module, and its first data-oriented kernel bug: the primitive is an arbitrary file content overwrite, not memory corruption.

🟢 Full chain (--full-chain), VM-verified end-to-end. skeletonkey --exploit refluxfs --i-know --full-chain lands root: it reflink-clones /etc/passwd, races the CoW window, strips root's password field on disk (root:x: → root::), evicts the stale page cache, and returns EXPLOIT_OK; su root (empty password) then gives uid 0. Without --full-chain the module runs a safe reachability trigger only, confined to files the caller owns. See "Full-chain verification" below.

The bug

xfs_direct_write_iomap_begin() (fs/xfs/xfs_iomap.c) reads the data-fork extent map under ILOCK. To allocate a transaction it must wait for log space, so xfs_reflink_fill_cow_hole() (fs/xfs/xfs_reflink.c) drops ILOCK. On re-acquiring it, the code re-queries the refcount btree at the original physical block number (imap->br_startblock) — and never re-reads the data fork.

A second O_DIRECT writer, holding only the coarser IOLOCK, can complete an entire CoW cycle inside that window: allocate block Y, write it, and remap via xfs_reflink_end_cow(). The first writer's imap now points at a block owned solely by the reflink source. Its stale refcount lookup returns 1, it concludes the block is private, and writes to it in place — landing attacker data on the source file's on-disk blocks.

Three consequences follow, and they drive the whole module design:

1. No offsets, no ROP, no KASLR/SMEP/SMAP. There is nothing to port per kernel build. Qualys is explicit that SELinux enforcing, container boundaries and seccomp are equally irrelevant.
2. The victim's inode is never written. The data is applied to the shared physical block underneath it, so mtime/ctime/size do not change and there is no kernel log output. File-integrity monitoring does not fire.
3. It persists across reboots, because the change is on disk.

The public demonstration (RHEL 10.2) reflink-clones /etc/passwd into /var/tmp, races concurrent direct-I/O writes against the clone, thereby rewriting /etc/passwd itself to strip root's password, and runs su.

Affected range

Introduced	4.11 (2017-02, commit 3c68d44a2b49, "xfs: allocate direct I/O COW blocks in iomap_begin")
Fixed upstream	commit 2f4acd0fcd86 ("xfs: resample the data fork mapping after cycling ILOCK") — merged 2026-07-16, released 7.2-rc4
Stable backports	7.1.4 (e705d81a7193) · 6.18.39 (206c09b04dc5) · 6.12.96 (44f891bc0889)
Affected, no upstream fix	6.6 / 6.1 / 5.15 / 5.14 / 5.10 / 4.19 / 4.18 LTS lines (per the CNA record at time of writing)
Not affected	< 4.11 — includes RHEL/CentOS 7 (3.10 predates reflink)
NVD class	CWE-362 (race) → CWE-367 (TOCTOU). NVD had published no CWE and no CVSS vector at time of writing
CISA KEV	no (disclosed 2026-07-22)

The exposure is distro-shaped, not kernel-shaped. What matters is whether XFS+reflink is the installer default:

Exploitable out of the box	Not reachable by default
RHEL 8/9/10 · CentOS Stream 8/9/10 · Rocky/AlmaLinux 8/9/10 · Oracle Linux 8/9/10 (RHCK + UEK R6/R7/8) · CloudLinux 8/9/10 · Fedora Server ≥ 31 · Amazon Linux 2023 (and AL2 AMIs from 2022-12)	Debian · Ubuntu · Fedora Workstation · SLES · openSUSE · Arch (ext4/btrfs defaults — unless an XFS volume was added deliberately)

⚠️ The version gate has a real blind spot here

The affected population is overwhelmingly RHEL-family, and those vendors backport fixes without bumping the upstream base version — a patched RHEL 8 kernel still reports 4.18.0-xxx.el8. An upstream-version gate cannot see that.

So on rpm-family hosts, a VULNERABLE verdict is a statement about the upstream base version only. detect() prints that warning explicitly rather than implying it checked the erratum. Confirm against the vendor advisory (RHSA / ELSA / ALSA / RLSA) before acting on it.

Trigger / detection

Unlike a pure kernel race, this bug's reachability can be established safely and deterministically, so detect() is a version gate plus a real precondition probe:

• Passive — is there a writable directory on a mounted XFS filesystem? Identified via statfs(2) f_type == XFS_SUPER_MAGIC, not by a successful FICLONE, because btrfs implements FICLONE too and is unaffected. No such directory → PRECOND_FAIL, the correct verdict on a stock Debian/Ubuntu host.
• Active (--active / --auto) — confirms reflink=1 empirically by cloning and removing two 4 KiB files, rather than assuming the mkfs.xfs default. reflink=0 → no shared extents can exist → PRECOND_FAIL.
• Override — SKELETONKEY_XFS_ASSUME_REFLINK=1 (force reachable) / 0 (force unreachable), for when you know the fleet's storage layout better than a local probe can. This also drives the unit tests.

--full-chain — the real /etc/passwd root pop

With --full-chain, exploit() performs the actual privilege escalation:

1. Pre-flight, before touching anything. Confirms the target (/etc/passwd, or $SKELETONKEY_REFLUXFS_TARGET) is root-owned and fits in one block, and crafts the payload first — the original file with root's password field emptied (root:x: → root::), every other line preserved byte-for-byte, padded with newlines to the exact original size. If it cannot produce a payload that keeps both root and the invoking user's line, it refuses and touches nothing. (A naive port that truncates the tail drops sshd/nobody/the caller and bricks login — this is the single most important safety property of the implementation.)
2. Backup. Copies the target aside so failure or cleanup() can restore it.
3. Race. 32 writers push the crafted block at a reflink-clone of the target while 8 helpers churn ftruncate/fdatasync, up to a 90 s budget. A won race lands the crafted block on the target's still-shared physical block.
4. Cache eviction. The overwrite bypasses the target inode, so its clean page-cache pages are never invalidated — a su immediately after would read the stale old passwd. The module issues POSIX_FADV_DONTNEED (needs only an O_RDONLY fd) so subsequent buffered readers see the new bytes.
5. Verify (via O_DIRECT, not the cache) and report. Confirms the on-disk root line is now root::; if the write was torn, it restores from backup and fails. On success returns EXPLOIT_OK and prints su root (empty password).

cleanup() (run as root after the pop) restores /etc/passwd from the backup. The overwrite is persistent and survives reboot, so restoring matters.

The private-extent precondition (not in the public writeup)

The race only fires when the target's extent refcount is exactly the attacker-clone pair — i.e. the target's extent must be private going in. The mechanism: the block starts at refcount 2 (target + attacker clone), the concurrent CoW drops it to 1, and the stale writer then reads "1 → private". If the target is already reflink-shared with a third file, the post-CoW refcount stays > 1, the writer correctly does CoW, and nothing corrupts.

This was found during verification: the stock Rocky 9 cloud image ships /etc/passwd pre-shared (its block had refcount > 1 in the base image), and the attack failed against it across ~41 000 rounds. Rewriting the file so its extent became private — with byte-identical content, exactly what any useradd/passwd/vipw does — made it fall in ~2 000 rounds. So the exploitable state is the normal administered state; the cloud image was accidentally protected by how it was built. detect() --active reports the target's extent state (filefrag -v /etc/passwd | grep shared checks it by hand), and the full chain warns when the target is pre-shared.

--full-chain verification (2026-07-23, Rocky 9.8)

On 5.14.0-687.10.1.el9_8.0.1.x86_64, unprivileged uid=1000, SELinux Enforcing, against a private-extent /etc/passwd:

--exploit refluxfs --i-know --full-chain	EXPLOIT_OK, 3/3 wins (1244 / 3716 / 7913 rounds, 4–30 s)
su root (empty password) afterwards	uid=0(root)
Accounts preserved	all 25 lines; root/sk/sshd/nobody intact
/etc/passwd metadata after overwrite	size/inode/mtime/ctime unchanged, only content — FIM-invisible
cleanup (as root)	restored /etc/passwd from backup, removed backup
Plain --exploit (no --full-chain)	safe trigger, EXPLOIT_FAIL, target untouched
Pre-shared /etc/passwd	not attackable (~41 000 rounds, no win) — as predicted

The safe default trigger

Without --full-chain, exploit() forks an isolated child that creates a private mkdtemp scratch directory on the XFS mount and works only on two files it owns:

• (A) deterministic + safe — writes a donor file, FICLONE-clones it, and confirms via FIEMAP_EXTENT_SHARED that the clone's extent really is shared (refcount > 1), plus that O_DIRECT opens succeed. That is a read-only observation that the exact filesystem state the bug misjudges exists here. Reflink cloning is an ordinary supported operation, so this phase is safe on any kernel.
• (B) hard-bounded window exercise — races 8 concurrent O_DIRECT 4 KiB writes against the clone while 2 helper threads cycle ftruncate/fdatasync to keep the transaction allocator dropping ILOCK to wait for log space, for at most 16 rounds / 2 s. Then it stops and reads the donor back with O_DIRECT — a buffered read would be served from the page cache that the corruption bypasses, and would hide a win.

This default path is deliberately under-driven (the public PoC and the --full-chain path use 32 writers and 8 helpers) and never clones or targets a file it does not own — the destructive /etc/passwd overwrite lives only behind --full-chain (above). The default exploit() always returns EXPLOIT_FAIL.

If the race is won on the safe path, the module says so loudly: that is CVE-2026-64600 confirmed present, empirically, with the damage contained to 4 KiB of the operator's own scratch file.

VM verification (2026-07-23)

Confirmed on Rocky Linux 9.8 / 5.14.0-687.10.1.el9_8.0.1.x86_64 under qemu/KVM with 6 vCPUs — the stock GenericCloud installer layout, root on /dev/vda4 XFS with reflink=1, no provisioner changes:

Check	Result
detect() on real XFS	VULNERABLE (found writable XFS at /var/tmp)
rpm-family backport caveat	fired correctly
--active FICLONE witness	reflink CONFIRMED
Phase A shared extent	FIEMAP_EXTENT_SHARED set (btrfs never reported it; XFS does)
Phase A O_DIRECT gate	available
Shipped trigger (8 writers / 2 helpers / 2 s)	ran 16 rounds, did not win — by design
Scratch cleanup	no artifacts left
Build on el9 gcc	clean

The underlying bug was separately confirmed winnable on that kernel. The --full-chain run above is the definitive proof — the same reflink-CoW race rewrote /etc/passwd and landed root 3/3 (1244 / 3716 / 7913 rounds). An earlier non-destructive measurement, driven at the public PoC's parameters (32 writers / 8 helpers, 60 s) but confined to two files the test user owned, won 4/4 (first divergence after 69, 114, 170 and 494 rounds): a racing O_DIRECT write landing on a still-shared block and rewriting the donor's on-disk bytes — the arbitrary-overwrite primitive, observed directly, contained entirely to attacker-owned files.

Note carefully what this does and does not say. The shipped trigger not winning in 2 s on a kernel that is provably vulnerable is exactly the designed behaviour, and is the concrete reason a non-win must never be read as "patched" — trust the version gate and the vendor erratum instead.

Why this ranks above the other reconstructed race triggers

bad_epoll (12) and ghostlock (11) sit at the bottom of the --auto safety ranking because a won race frees a live struct file or corrupts the kernel stack — silent destabilisation or near-certain panic. Neither applies here. RefluXFS corrupts file data, not kernel memory: there is no oops, no KASAN report, no panic risk, and the blast radius of a win is one 4 KiB scratch file we created and delete. That is why refluxfs carries safety rank 55 — it is genuinely safe to run, and the ranking should say so. The VM run above bears this out: the bug was won 4/4 times on a vulnerable kernel with no oops, no dmesg output and no instability.

Detection — the obvious rule does not work

Do not rely on -w /etc/passwd -p wa, AIDE, or Tripwire for this CVE. The attacker never issues a write(2) against the victim inode; XFS applies their data to the shared physical block beneath it. Size, mtime and ctime are unchanged and nothing is logged. Anyone relying on FIM to catch a passwd modification is blind to this bug by construction.

What does work, in descending order of fidelity:

1. The reflink itself — ioctl(fd, FICLONE, srcfd) where FICLONE is 0x40049409. auditd can match the request number exactly, so it does not flood, and the attack cannot avoid it. Tune out cp --reflink=auto, podman and systemd-nspawn image work.
2. O_DIRECT opens — openat flags & 0x4000. Also on the critical path, and rare outside databases and backup agents.
3. Content-vs-metadata drift — because the bytes change while mtime does not, hashing /etc/passwd, /etc/shadow and the setuid binaries on a schedule and alerting when the content hash moves without a corresponding mtime change is a near-zero-false-positive detector for this whole bug class.

The shipped rules cover all three: auditd/sigma anchor on the FICLONE request number and O_DIRECT opens (correlated per-pid, plus the post-exploitation euid-0 transition), falco adds the high-fidelity "reflinked a file owned by another user" condition, and — unusually for a kernel bug — the yara rule is genuinely the right tool, matching the on-disk artifact (/etc/passwd with a password-less root entry or an added uid-0 account) precisely because there is no metadata trace for FIM to find.

Fix / mitigation

Upgrade the kernel (≥ 7.1.4 / 6.18.39 / 6.12.96 on-branch, or 7.2+; on RHEL-family, the vendor erratum) and reboot.

There is no partial mitigation, which is why mitigate() is NULL: reflink is a superblock feature that cannot be disabled on a live filesystem, O_DIRECT cannot be turned off, and — because this is a data-oriented bug — SELinux enforcing, container boundaries, KASLR, SMEP, SMAP and seccomp are all irrelevant. Qualys puts it plainly: "This isn't a vulnerability you can harden around, isolate, or live-patch."

cleanup() restores /etc/passwd from the --full-chain backup (run it as root after the pop: su root, then skeletonkey --cleanup refluxfs), then sweeps any skeletonkey-refluxfs-* scratch directories left behind if a run was killed mid-round; normal runs remove their own.

Credit

Discovery and research: Qualys Threat Research Unit (TRU); the blog post is authored by Saeed Abbasi, and the technical advisory credits model-assisted kernel analysis performed with Anthropic. Upstream fix 2f4acd0fcd86. See NOTICE.md.