New RefluXFS Linux Flaw Survives Reboots and Evades Logs

Live this afternoon: We’re breaking down RefluXFS with a Linux patching expert, including the latest vendor coverage and how to close it without a reboot. Watch it here →

The Short Version

Jump to the Long Version ↓

What it is: RefluXFS, tracked as CVE-2026-64600, is a race condition in the Linux kernel’s XFS copy-on-write path. It lets an unprivileged local user redirect a write from a reflinked copy back into the original file’s physical disk block, so an attacker can alter a root-owned file they are allowed to read but have no permission to write. Jump to the Long Version →

Impact: Local privilege escalation to root. Qualys demonstrated it against /etc/passwd and setuid-root binaries on default enterprise Linux, removing the root account’s password protection on a stock RHEL 10.2 system within seconds. The write lands below the normal inode write path, so it can preserve the target’s owner, permissions, timestamps, and setuid bit, survives a reboot, and produced no kernel log output in Qualys’ testing. Jump to the Long Version →

Severity: No public CVSS score had been confirmed at the time of writing. Treat it as high priority regardless: exploitation is reliable, needs only an ordinary local account, bypasses common hardening, and yields persistent root. Red Hat rates it Important. Jump to the Long Version →

Who’s affected: Linux kernels based on version 4.11 or later that contain the vulnerable XFS code and do not carry the fix, on an XFS filesystem created with reflink support, where a readable protected file and an attacker-writable directory share that filesystem. That describes the default layout on RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, and CloudLinux 8, 9, and 10, plus Fedora Server 31 and later, Amazon Linux 2023, and Amazon Linux 2 images from December 2022 on. RHEL 7 predates XFS reflink and is outside the default exposure. Jump to the Long Version →

Status: Publicly disclosed by Qualys on July 22, 2026, and found with AI assistance under Anthropic’s Project Glasswing. The upstream fix merged July 16, and vendors have shipped backported kernels. Some enterprise fixes went out before disclosure as ordinary kernel updates, so a host may already carry the correction even if the update never mentioned CVE-2026-64600. Jump to the Long Version →

Do this now: There is no risk-free configuration workaround. Red Hat has published a temporary SystemTap mitigation, but the real fix is a patched kernel: check whether each XFS filesystem uses reflinks, apply the fixed kernel for your exact release and reboot, or apply a KernelCare rebootless patch (which are deployed automatically to users in the background). Jump to the Long Version →

xfs_info / | grep reflink=

A result of reflink=1 confirms the filesystem prerequisite. Repeat for other mounted XFS volumes that hold both protected files and attacker-writable directories.

RefluXFS breaks one of the filesystem’s most basic promises: that being allowed to read a protected file does not let you rewrite it.

The attacker never opens /etc/passwd or a setuid-root binary for writing. Linux would deny that outright. Instead they ask XFS to make a reflinked copy of the file somewhere they control, then race two direct writes against that copy. Because of a stale block mapping inside the kernel, one of those writes can land in the original protected file instead of the copy. The attacker writes to a file they control, but the root-owned original changes.

That one primitive is enough to blank the root password, rewrite authentication data, or plant attacker code in a setuid-root binary so it runs as root. On a default RHEL 10.2 install, Qualys did it in seconds.

One detail is worth pausing on, particularly for the live-stream discussion. RefluXFS was found under Anthropic’s Project Glasswing: Qualys pointed Claude Mythos Preview at the kernel and asked it to hunt for a Dirty COW style race, then its own researchers reproduced the finding, verified every claim, and ran the coordinated disclosure. AI accelerated the hunt; humans confirmed and disclosed it. Read it as a preview of where kernel bug-finding is going, not as push-button exploitation.

Two things will still tempt you to file this low. The first is the phrasing on the original vendor update, which shipped as a plain “XFS data corruption” fix and reads like a data-integrity annoyance. It is a reliable local root primitive. The second is reflink itself, which sounds like an exotic option nobody enables. It has been the mkfs default on the RHEL-family root filesystem for years, so on a stock box you already meet the condition without asking.

XFS reflinks let two files point at the same physical disk blocks without duplicating the data. When one file is written, XFS performs copy-on-write: it allocates a new block for the changed file, copies the data, remaps that file, and drops the original block’s reference count. The original file is supposed to stay untouched.

RefluXFS is what happens when two writes race through that sequence.

[Attacker reflink-clones a readable root-owned file]
                     |
                     v
[Both files temporarily reference the same disk blocks]
                     |
                     v
[Two concurrent O_DIRECT writes race against the clone]
                     |
                     v
[XFS drops the inode lock to reserve transaction space]
                     |
                     v
[One path keeps using a stale physical block mapping]
                     |
                     v
[The write reaches the original protected file's disk block]
                     |
                     v
[Protected file changes with no normal write to its inode]

The vulnerable code reads the file’s data fork under the inode lock, then releases the lock to reserve transaction log space. During that gap, a second writer can finish its own copy-on-write cycle, remap the clone to a fresh block, and drive the original block’s reference count down to one. When the first writer reacquires the lock, it rechecks whether the block is still shared, but it checks against the physical address it captured before the lock was dropped. That address is a stale data-fork mapping. XFS sees a count of one, concludes the block is private, and writes into it, even though that block now belongs only to the protected source file.

Because O_DIRECT bypasses the page cache, there is no revalidation and the write goes to disk. It is a time-of-check-to-time-of-use race across an inode-lock cycle. The permission check was never wrong. The kernel just acted on a block address that had gone stale.

The fix makes XFS re-read the data-fork mapping after it detects the mapping may have changed while the lock was released:

Before:
read mapping -> release lock -> mapping changes -> reuse stale mapping -> wrong file overwritten

After:
read mapping -> release lock -> mapping changes -> reread mapping -> write follows current mapping

Qualys’ write-up locates the lock drop in xfs_reflink_allocate_cow(). The mainline commit, titled “xfs: resample the data fork mapping after cycling ILOCK,” merged July 16 and re-samples the mapping in the affected CoW helpers. It changes no on-disk format and no kernel data-structure layout, which matters later for rebootless patching.

The overwrite happens at the block layer and skips the protected file’s normal inode-level write path. That defeats several signals commonly used for file-change detection:

• The target keeps its original owner and permission mode.
• Its setuid bit stays in place, so a tampered setuid-root binary still runs as root.
• Its timestamps need not reflect the change.
• Path-based file-activity monitoring may not record a write against the protected target itself.
• The modified data stays on disk after a reboot.
• Qualys observed no corresponding kernel warning or log entry.

This is why RefluXFS is worse than a transient memory-corruption bug. It is a persistent on-disk modification primitive that leaves most of the signals defenders expect untouched. A file-integrity tool that hashes file contents can still catch it. Tools that lean on metadata, path-based audit records, or kernel warnings will not.

Three conditions must all hold:

1. The system runs an affected Linux kernel based on 4.11 or later, without the fix.
2. The relevant XFS filesystem was created with reflink support.
3. A readable protected target and an attacker-writable directory sit on that same filesystem.

Check the root filesystem, and every mounted XFS volume where untrusted local code can run, since a separate data volume can be exposed even when root is not:

xfs_info / | grep reflink=

Output containing reflink=1 means the filesystem prerequisite is present.

Qualys lists RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, and CloudLinux 8, 9, and 10 among the commonly affected enterprise distributions, along with Fedora Server 31 and later, Amazon Linux 2023, and Amazon Linux 2 AMIs released from December 2022 onward.

Debian, Ubuntu, SLES, openSUSE, and Fedora Workstation do not use XFS for root by default, and are exposed only if an administrator chose XFS with reflink enabled. RHEL 7 filesystems predate XFS reflink support and are outside the default exposure described here.

Do not try to reason your way to “safe.” The race only fires when the target block starts unshared, which tempts an assumption that a file you already reflink-copied is immune, but an unprivileged user can reset that state, and setuid-root binaries are unlikely to have been reflinked in the first place. That apparent restriction does not provide a reliable safety boundary.

Our kernel team reproduced the vulnerability on the following builds and verified that the corresponding vendor builds contain the correction:

These are specific point releases. Coverage is stream-specific, so confirm the advisory for your exact release rather than assuming from a nearby version.

Default Enterprise Linux Layouts Make Exploitation Practical

The same-filesystem requirement sounds restrictive. On a typical enterprise install, it is not, because the default single-root-XFS layout puts all of this on one volume:

• Root-owned executables under /usr/bin
• Authentication data under /etc
• The world-writable /tmp
• User home directories under /home

That hands an unprivileged user both readable high-value targets and writable scratch space on the same reflink-enabled filesystem. Picture the environments where that lands: a shared build host, a CI runner executing whatever the last merge request pushed, a multi-tenant node where containerized or restricted workloads can access suitable paths on the same host XFS filesystem, a developer box running untrusted dependencies. In each, an ordinary account is all the exploit needs.

This is host-local privilege escalation, not remote code execution and not a guest-to-hypervisor escape. An attacker has to get local code execution first. Once they do, RefluXFS turns that foothold into host root.

Why Common Linux Hardening Does Not Stop It

RefluXFS is not a conventional kernel-memory-corruption exploit. It abuses normal filesystem operations to steer a write to the wrong physical block, which is why many common defenses miss it:

• SELinux: Qualys reproduced exploitation with SELinux in Enforcing mode.
• KASLR, SMEP, and SMAP: these guard memory-corruption paths, not filesystem block allocation, so they never engage.
• Kernel lockdown: it places no restriction on ordinary reflink or direct-I/O operations for unprivileged users.
• Containers and namespaces: they do not automatically block access to the vulnerable filesystem path.
• Seccomp: typical profiles permit the ordinary file operations the attack uses.
• Rebooting without updating: the corrupted file survives, and booting the same vulnerable kernel leaves the flaw available.

No special capabilities are needed. No CAP_SYS_ADMIN, no privileged namespace, no unusual hardware, no custom kernel configuration. The XFS, reflink, and same-filesystem prerequisites still apply, but they are present by default on many affected enterprise Linux installations.

There is no risk-free configuration workaround, but Red Hat has published a temporary runtime mitigation.

reflink is selected when the XFS filesystem is created. There is no mount option or sysctl that converts an existing reflink=1 filesystem into a non-reflink one, and recreating the filesystem is not an emergency response for production. Removing setuid bits from su, sudo, or pkexec breaks normal operation and is not a targeted fix.

Red Hat Product Security has published an interim SystemTap mitigation that intercepts the XFS reflink entry point and forces reflink operations to return an unsupported-operation error. A similar approach is possible with kprobes. This blocks the vulnerable reflink path, but it changes filesystem behavior and may affect applications that rely on reflink cloning, so validate it in a test environment first. Treat it as a temporary protection for systems that cannot be patched immediately, not as a replacement for a fixed kernel.

The real remedy is a corrected kernel, either rebooted or not.

Installing a kernel package does not change the kernel already running in memory. For a conventional vendor update: install the kernel update for your exact release, reboot, and confirm you booted into it.

uname -r

For the specific streams listed above, the tested fixed builds are 4.18.0-553.144.1.el8_10, 5.14.0-687.26.1.el9_8, and 6.12.0-211.34.1.el10_2. Verify your running kernel against the advisory for your exact distribution, stream, and architecture.

There are two traps to avoid. Do not judge by the newest package on disk; judge by the running kernel. And do not assume every kernel built after July 16 carries the fix, because distribution version numbers do not map to upstream releases and some streams backported it earlier. Verify against the vendor advisory for the specific stream. Because some vendors shipped the correction before the CVE was public, CVE-keyed scanners may not tell the whole story about historical patch status.

Rebootless Patching

RefluXFS suits rebootless patching well. The fix is a focused change to how the XFS code refreshes a block mapping after cycling the inode lock, with no on-disk format change and no kernel data-structure replacement across the system.

Qualys’ public advisory recommends installing a fixed kernel and rebooting, and correctly notes that reflink cannot be disabled on an existing live filesystem.

KernelCare takes a different remediation path: it applies the underlying XFS code correction directly to the running kernel rather than attempting to disable reflink or change the filesystem configuration.

The vulnerable CoW path then resamples the data-fork mapping after the lock cycle without a maintenance window or a workload restart. It is a kernel-only bug, with no userspace-library component to chase.

KernelCare users generally have patches set up so that all new fixes are deployed automatically, in the background, at specific intervals – like every 4 hours, for example. However, users can also apply any patch from the production feed once promoted:

kcarectl --update

Confirm the CVE mapping rather than trusting a build date, since a kernel compiled after mid-July does not automatically carry this fix:

kcarectl --patch-info | grep 'CVE-2026-64600'

Where a patch is still promoted through the testing feed for your kernel family, confirm availability before relying on rebootless coverage, and reboot into the fixed vendor kernel in the meantime.

Get KernelCare today →

Detection and Incident Review

There is no single reliable RefluXFS indicator, so treat each of the following as a lead, not proof.

The sharpest on-disk check exploits the bug’s own blind spot: the content changed but the metadata did not. Package verification hashes file contents, so it trips even when mtime and mode look clean. Start with package verification for security-sensitive packages:

rpm -V shadow-utils sudo util-linux polkit

A 5 in the verification-result string indicates a digest mismatch. On a setuid-root binary or core configuration file, with no corresponding T timestamp or M mode change, that is consistent with the type of modification RefluXFS can leave. On Debian-family systems, debsums -c fills the same role. Package verification will not cover every important mutable configuration file, so supplement it with trusted backups, configuration-management records, and known-good file hashes.

Focus on the high-value targets:

/etc/passwd   /etc/shadow   /etc/sudoers
/usr/bin/su   /usr/bin/sudo   /usr/bin/passwd   /usr/bin/pkexec

Then look for the behavioral signals: unexpected passwordless or new privileged accounts, changed root-account fields, setuid programs whose contents no longer match the installed package, unexplained SSH keys, privilege gains with no matching sudo, login, or authentication event, bursts of concurrent direct-I/O from an unprivileged process, and reflink cloning of protected files into user-writable locations.

A normal timestamp or unchanged permission mode does not clear a file. If untrusted code ran on a vulnerable host during the exposure window, treat it as a possible integrity compromise and look harder at accounts, auth configuration, and services, rather than reading a quiet kernel log as evidence of safety.

Why RefluXFS Matters

RefluXFS is easy to underrate because three details all sound limiting. It is local, not remote. It needs XFS. It needs reflinks.

On enterprise Linux, those three describe the default environment, and the machines that match are exactly the ones running other people’s code: tenants, build pipelines, containers, plugins, compromised services.

The flaw also crosses the security boundary in an unusual way. No direct write to the protected file, no SELinux to defeat, no kernel-memory payload. The kernel simply writes valid, attacker-controlled data to the wrong disk block, and the result is persistent, root-owned, and quiet.

There is a process lesson here too, and it is the one to carry into your triage queue. For many administrators, the first publicly actionable signal may have been an ordinary vendor kernel update shipped before the CVE disclosure and described as an XFS data-corruption fix. That is the silent fix-first, CVE-later pattern, and a queue that keys only on security errata would have filed a root-capable local LPE as routine maintenance. Watch kernel bugfix advisories, not just the ones flagged as security.

For conventionally patched systems, install the vendor update and confirm the machine actually boots into it. For fleets where emergency reboots create their own operational risk, a KernelCare rebootless patch closes the vulnerable XFS path in the running kernel without draining nodes or interrupting workloads.

Get KernelCare today →

Timeline

References

• Qualys, “RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600),” July 22, 2026: https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
• Qualys technical advisory, “RefluXFS: Local Privilege Escalation via XFS reflink direct-I/O race,” oss-security 2026/q3, July 22, 2026
• Red Hat Product Security interim SystemTap mitigation, oss-security mailing list (CVE-2026-64600 thread)
• Red Hat CVE page, CVE-2026-64600: https://access.redhat.com/security/cve/cve-2026-64600
• Red Hat security errata RHSA-2026:39179 and RHSA-2026:39180 (RHEL 8), RHSA-2026:39494 (RHEL 10)
• Upstream fix, “xfs: resample the data fork mapping after cycling ILOCK” (commit 2f4acd0), merged July 16, 2026
• Bug-introducing commit 3c68d44a2b49, “xfs: allocate direct I/O COW blocks in iomap_begin” (Linux 4.11)
• The Hacker News, “Nine-Year-Old RefluXFS Linux Flaw Gives Local Users Root on Default RHEL Installs”: https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html
• Applicable AlmaLinux, Rocky Linux, Oracle Linux, Fedora, and Amazon Linux distribution advisories