A newly disclosed Linux kernel vulnerability is drawing attention across the security community after researchers demonstrated that an ordinary local user can escalate privileges to full root by exploiting a race condition deep inside the XFS filesystem. Tracked as CVE-2026-64600 and dubbed RefluXFS, the flaw affects the copy-on-write (CoW) implementation used by XFS when handling reflink-enabled files. Successful exploitation allows an attacker to overwrite protected files directly on disk, bypassing many of the operating system’s traditional security controls.
Unlike many local privilege escalation vulnerabilities that rely on corrupting kernel memory or abusing a driver bug, RefluXFS targets the filesystem itself. The attack manipulates how XFS manages shared data blocks during concurrent direct I/O operations, ultimately causing legitimate writes to land on disk blocks that belong to an entirely different file. The result is a reliable primitive that can modify security-sensitive files such as /etc/passwd or SUID-root binaries without altering their ownership, permissions, or inode metadata. Because the corruption occurs below the page cache, the changes are written permanently to disk and survive system reboots.
Qualys Threat Research Unit (TRU), which discovered the vulnerability, demonstrated exploitation on a default Red Hat Enterprise Linux 10.2 installation. Starting with nothing more than an unprivileged user account, researchers were able to remove the root account’s password protection within seconds and obtain passwordless root access. Throughout the attack, the kernel produced no warning messages or audit logs indicating that protected files had been modified through an exploit.
The vulnerability has existed since Linux kernel 4.11, released in April 2017, meaning nearly a decade of Linux releases inherited the flaw before it was identified and patched upstream. According to Qualys, enterprise distributions that deploy XFS with reflink support enabled by default are among the most exposed, making this one of the more significant Linux local privilege escalation disclosures of 2026.
Summary
RefluXFS is fundamentally a race condition inside the XFS copy-on-write allocation path. Two concurrent O_DIRECT write operations targeting the same reflinked file can trigger an inconsistency between block mapping information and the filesystem’s reference counting logic. One thread resumes execution using outdated information after temporarily releasing an inode lock, eventually writing directly into a physical block that should no longer belong to the attacker’s file. That seemingly small synchronization mistake has severe consequences.
Instead of modifying only the attacker’s cloned copy, the kernel ends up writing into the original shared disk block backing another file. Since the write bypasses the page cache through direct I/O, there is no second validation step before data reaches storage. The filesystem therefore commits attacker-controlled bytes directly onto the victim file.
From an attacker’s perspective, this primitive is extremely powerful because it provides reliable arbitrary modification of readable files residing on the same reflink-enabled XFS filesystem. Once a critical authentication file or SUID executable has been altered appropriately, obtaining root privileges becomes straightforward.
Who Is Affected?
Although the vulnerability exists in kernels dating back to 2017, exploitation requires several specific conditions.
First, the system must be running Linux kernel 4.11 or later without the upstream fix or an equivalent vendor backport. Nearly every modern enterprise kernel initially met this requirement before security updates became available. Second, the target filesystem must use XFS with reflink enabled. This detail is important because reflink support fundamentally changes how XFS stores duplicated files. Third, the attacker needs local code execution under an ordinary user account and access to a writable directory located on the same XFS filesystem as a valuable target such as /etc/passwd or a SUID-root binary. On default single-volume installations, these requirements are commonly satisfied because directories like /var/tmp reside alongside system files on the root filesystem.
Qualys confirmed the vulnerability across several enterprise Linux families, including:
- Red Hat Enterprise Linux 8, 9 and 10
- CentOS Stream
- Oracle Linux
- Rocky Linux
- AlmaLinux
- CloudLinux
- Amazon Linux 2 and Amazon Linux 2023
- Fedora Server
Debian, Ubuntu and SUSE installations are generally considered lower risk because they typically default to ext4 or other filesystems rather than XFS. However, systems where administrators intentionally selected XFS with reflink support remain vulnerable until patched
Understanding XFS and Why Reflink Exists
To understand RefluXFS, it is necessary to understand why XFS implements reflinks in the first place.
XFS is a high-performance 64-bit journaling filesystem originally developed by Silicon Graphics before eventually becoming part of the Linux kernel. It has long been favored for enterprise workloads involving databases, virtualization platforms, large storage arrays and cloud infrastructure because of its scalability and efficient parallel I/O handling.
Traditional file copying is expensive. When a file is duplicated using conventional methods, every block must be physically copied to another location on disk. A 20 GB virtual machine image therefore requires another 20 GB of storage and substantial disk I/O before the copy operation completes.
Reflinks solve this problem differently. Rather than immediately duplicating data blocks, XFS simply creates another inode that references exactly the same physical storage blocks. Initially, both files point to identical disk locations.
The filesystem records that those blocks are now shared. No additional disk space is consumed until somebody attempts to modify one of the copies. This behavior is known as Copy-on-Write (CoW). Instead of changing the shared block directly, XFS allocates a brand-new private block, copies the existing data into it, updates the modified file’s metadata to reference the new block, and finally performs the requested write operation.
The untouched file continues referencing the original block while the modified copy points elsewhere. From the user’s perspective, both files become independent without ever observing the transition. This optimization significantly reduces storage consumption while making cloning operations almost instantaneous. Modern backup systems, virtual machine platforms and container storage drivers rely heavily on this capability because it enables efficient snapshots and rapid duplication of very large datasets.
The entire design depends on one critical guarantee – Shared blocks must never be modified directly.
Every write must first determine whether the underlying block is shared with another file. If it is, Copy-on-Write must successfully complete before any bytes reach storage. RefluXFS exists because that guarantee briefly breaks down under a very specific race condition.
Copy-on-Write Inside XFS
Internally, XFS maintains metadata describing which physical blocks belong to which files and how many files currently reference each block.
Suppose two files reference the same physical extent. The filesystem’s reference count indicates that the block is shared. When an application writes to one of those files, XFS cannot simply overwrite the shared storage because doing so would silently modify every other file pointing to that block.
Instead, the filesystem performs several operations. It allocates free storage elsewhere on disk. It copies the original data into that new location. It updates the file’s mapping so future reads use the newly allocated block. Finally, it decreases the reference count associated with the old shared block because one fewer file depends on it.
Only after those steps complete can the requested write safely occur. These operations must remain synchronized because multiple processes may simultaneously access the same files. For that reason, XFS relies on inode locking and transaction management to ensure metadata remains internally consistent while Copy-on-Write is in progress.
RefluXFS exploits a rare situation where that synchronization temporarily breaks.
What Makes O_DIRECT Different?
The second major ingredient behind RefluXFS is Linux’s O_DIRECT flag.
Normally, file writes pass through the kernel page cache. Applications modify cached memory pages first. The kernel later flushes those pages to storage, performing additional validation, synchronization and consistency checks before data reaches disk.
Direct I/O changes that behavior entirely. When a file is opened using O_DIRECT, applications bypass the page cache and transfer data almost directly between user memory and the storage device. This reduces memory overhead and avoids cache pollution, making it attractive for databases, virtualization software and other performance-sensitive enterprise workloads.
However, bypassing the page cache also removes opportunities for the kernel to detect inconsistencies introduced after a write operation begins. Once XFS determines the destination block for a direct I/O request, the operation proceeds toward storage with minimal additional intervention.
That characteristic becomes particularly important during RefluXFS exploitation because stale block mappings are not automatically revalidated before the write reaches disk.
The Race Condition That Makes RefluXFS Possible
At the heart of CVE-2026-64600 lies a subtle synchronization failure inside XFS’s Copy-on-Write implementation. During a direct write targeting a reflinked file, XFS begins preparing a private copy of the shared data block. To perform this safely, the filesystem acquires the inode lock and records information describing the block currently being modified. Under certain conditions, however, XFS must wait for transaction log space before continuing.
Rather than blocking the entire filesystem while waiting, the kernel temporarily releases the inode lock. This design choice helps avoid deadlocks and improves scalability under heavy workloads. Unfortunately, releasing that lock briefly opens a race window.
While the first thread waits, a second thread writing to the same reflinked file can acquire the lock, complete its own Copy-on-Write operation, update the block mappings, decrease the original block’s reference count and finish execution. From the filesystem’s perspective, ownership of the underlying storage has already changed.
When the original thread resumes, it reacquires the inode lock but continues operating using mapping information captured before the lock was released. Instead of fully re-reading the updated block mapping, it consults the stale physical address recorded earlier.
Seeing what appears to be a reference count indicating exclusive ownership, the kernel mistakenly concludes the original block is now private and safe to overwrite. In reality, that physical block still belongs to another file. The subsequent direct I/O write therefore lands on the victim’s disk block rather than the attacker’s cloned copy. Because the write bypasses the page cache, there is no later opportunity to notice that the mapping changed while execution was suspended.
The corruption reaches persistent storage immediately, completing the primitive required for privilege escalation. Qualys notes that the upstream fix addresses this logic by resampling the data fork mapping after cycling the inode lock, ensuring stale mapping information cannot be reused after the lock is reacquired.
From Race Condition to Root: How RefluXFS Is Exploited
The exploitation chain behind RefluXFS is remarkably elegant because it never attempts to subvert Linux’s privilege model directly. There is no kernel shellcode, return-oriented programming (ROP), arbitrary kernel memory write, or manipulation of kernel credentials. Instead, the vulnerability abuses a logic flaw within XFS to obtain something arguably more valuable: the ability to overwrite the on-disk contents of privileged files while leaving their ownership, permissions, and metadata intact.
The attack begins with an ordinary user account. Since Linux permits users to read many system files, including /etc/passwd and numerous SUID-root executables, an attacker first creates a reflink clone of one of these targets using the FICLONE ioctl. Unlike a traditional copy, this operation merely creates another inode pointing to the same physical storage blocks. At this stage, no file contents have changed. Instead, the filesystem simply records that two files now share the same underlying blocks through XFS’s reference-count btree.
The attacker then repeatedly performs multiple synchronized O_DIRECT writes against the cloned file. Every thread enters the Copy-on-Write allocation path and eventually reaches the section where XFS temporarily releases the inode lock while waiting for transaction log space. This lock-drop window is exactly what the exploit attempts to win.
Eventually, one thread completes its Copy-on-Write operation first. XFS allocates a new private block, copies the original data, remaps the cloned file to the new location, and reduces the reference count associated with the original shared block.
A second thread, still operating with stale mapping information collected before the lock was released, resumes execution. Because the reference count now incorrectly appears to indicate exclusive ownership, the filesystem concludes that writing directly to the original physical block is safe. It is not. That physical block no longer belongs to the cloned file. It belongs exclusively to the original protected system file.
The write therefore lands directly inside the victim file instead of the attacker’s clone. Since the operation uses direct I/O, it bypasses the page cache entirely and is committed immediately to persistent storage. No subsequent validation step detects that the mapping became invalid while the thread was sleeping.
Qualys demonstrated this primitive by modifying /etc/passwd. Rather than replacing the file wholesale, the proof of concept performs a precise edit, removing the password placeholder from the root account entry. After invalidating the cached copy of the file, the attacker simply invokes su, which now accepts an empty password and returns a root shell. The same primitive can instead target SUID-root binaries because the vulnerability modifies only the underlying data blocks, leaving the inode metadata and SUID permission bits untouched.
The attack is highly reliable because it is fundamentally a race between two legitimate filesystem operations. The exploit repeatedly executes the race until the required timing occurs, widening the race window by creating contention in the XFS transaction log. On Qualys’ Fedora and RHEL test systems, successful privilege escalation generally occurred within seconds.
Why Traditional Linux Security Features Do Not Stop RefluXFS
One of the more concerning aspects of CVE-2026-64600 is that exploitation succeeds despite many of the hardening mechanisms administrators rely upon for defense in depth.
The reason is straightforward: those protections are designed to defend different parts of the operating system. Kernel Address Space Layout Randomization (KASLR) randomizes kernel memory locations to make exploitation of memory corruption bugs significantly more difficult. Supervisor Mode Execution Prevention (SMEP) prevents the kernel from executing code residing in user-controlled pages, while Supervisor Mode Access Prevention (SMAP) blocks unintended kernel access to user memory.
RefluXFS never interacts with kernel memory in this manner. The exploit neither injects code into the kernel nor redirects execution flow. Instead, it leverages legitimate filesystem operations to trick XFS into writing attacker-controlled data into an unintended physical disk block. Since no memory corruption occurs, memory-protection technologies never become relevant.
SELinux is similarly ineffective. Although SELinux successfully enforces access control decisions when applications request permission to read or modify files, RefluXFS does not bypass SELinux by violating those permissions. The attacker is allowed to read the original file and is allowed to write to their cloned copy. The vulnerability lies entirely within the filesystem’s implementation of Copy-on-Write, causing the kernel itself to write to the wrong disk block. During testing, Qualys confirmed successful exploitation with SELinux operating in Enforcing mode.
Kernel Lockdown mode also provides no meaningful protection because it focuses on preventing modifications to kernel integrity through mechanisms such as /dev/mem, unsigned kernel modules, and firmware interfaces. It does not restrict legitimate O_DIRECT writes or reflink operations.
Likewise, container isolation does not inherently mitigate the issue. Namespaces, capability restrictions, and seccomp filters govern process isolation and available system calls. RefluXFS operates underneath these abstractions in the filesystem allocation layer. A containerized workload capable of accessing a vulnerable reflink-enabled XFS filesystem could potentially exploit the same underlying race if other deployment conditions are satisfied.
AI Helped Discover the Bug, Humans Verified It
Beyond the technical details, RefluXFS has attracted attention because of how it was discovered.
According to Qualys, the research formed part of a collaborative initiative with Anthropic under Project Glasswing. Researchers tasked Claude Mythos Preview with identifying race conditions resembling Dirty COW within the Linux kernel. Rather than accepting the model’s output blindly, the team iteratively refined their prompts, narrowing the search toward filesystem code and memory-management components before the model identified the vulnerable XFS path.
The important distinction is that the AI model did not independently “discover” and responsibly disclose a vulnerability. Qualys researchers manually reviewed the model’s reasoning, reproduced the race condition, verified the proof of concept, validated every technical claim, coordinated disclosure with kernel maintainers, and authored the final advisory after human verification. Even the advisory itself underwent manual review before publication.
This reflects a broader trend emerging across vulnerability research, where large language models increasingly assist experienced researchers by identifying unusual code paths or suggesting hypotheses that still require expert validation. Rather than replacing security researchers, these systems currently function as force multipliers capable of accelerating manual auditing efforts.
Patch Availability and Mitigation
The vulnerability was introduced by a Linux kernel change merged during the Linux 4.11 development cycle in early 2017. The upstream fix was merged into the Linux kernel on July 16, 2026 through a patch that forces XFS to resample the data-fork mapping after cycling the inode lock, eliminating the stale mapping condition responsible for the race.
Enterprise Linux vendors have subsequently begun backporting the fix into supported kernel releases, including Red Hat Enterprise Linux, Oracle Linux, Rocky Linux, AlmaLinux, Fedora, and other downstream distributions. Administrators should install the latest vendor-provided kernel update and reboot affected systems to ensure the patched kernel is running. Simply installing updated packages without rebooting leaves the vulnerable kernel active.
Qualys emphasizes that there is currently no reliable configuration-based mitigation capable of eliminating the vulnerability. Unlike many local privilege escalation flaws, there is no sysctl, mount option, SELinux policy adjustment, or kernel hardening feature that reliably blocks exploitation.
One temporary workaround discussed by Red Hat engineers involves intercepting reflink operations using a SystemTap or kprobe-based script that forces XFS reflink requests to fail with -EOPNOTSUPP. This effectively disables new reflink cloning until systems can be patched, although it is intended only as an emergency mitigation because it changes filesystem behavior and may affect applications relying on reflinks.
Detection and DFIR Considerations
Unlike many kernel exploits, RefluXFS leaves very few traditional forensic indicators.
The exploit does not inject kernel modules, spawn suspicious kernel threads, or generate crash dumps. It exploits legitimate filesystem behavior, and successful attacks do not normally produce kernel warnings or dmesg entries. As a result, defenders should focus on evidence of unexpected modification to protected files rather than expecting explicit exploit telemetry.
During incident response, investigators should prioritize:
- Verifying the integrity of critical authentication files such as
/etc/passwd,/etc/shadow,/etc/group, and/etc/sudoers. - Checking SUID and SGID binaries for unexpected changes using package verification tools (
rpm -Va,debsums, or file integrity monitoring solutions). - Comparing filesystem contents against trusted backups or cryptographic baselines.
- Reviewing privileged account creation, password changes, and unexpected modifications occurring shortly before root access was obtained.
- Determining whether affected systems use XFS with
reflink=1enabled by examining filesystem configuration.
Because the attack modifies legitimate filesystem blocks rather than inode metadata, investigators should not assume timestamps alone provide a complete picture of compromise. File integrity monitoring remains significantly more valuable than relying exclusively on audit logs.
Indicators of Compromise
Unlike malware campaigns, CVE-2026-64600 does not have stable network-based or file-based IoCs such as IP addresses, domains, hashes, mutexes, registry keys, or YARA signatures. Any article claiming otherwise would be inaccurate.
Practical indicators include:
| Indicator | Description |
|---|---|
Unexpected modification of /etc/passwd or authentication files | Especially changes removing or altering root account authentication |
| Integrity verification failures | rpm -Va, debsums, AIDE, Tripwire, IMA/EVM or similar tools reporting modified protected files |
| Unexpected changes to SUID-root binaries | Modified executable contents while ownership and permission bits remain unchanged |
XFS filesystem configured with reflink=1 | Required prerequisite for exploitation |
| Unexplained local privilege escalation | Root access obtained without corresponding authentication or sudo activity |
These should be treated as investigative leads rather than definitive proof of exploitation.
Security Recommendations
Organizations should inventory systems using XFS, identify filesystems with reflink support enabled, and prioritize kernel updates across multi-user servers, virtualization hosts, development environments, and shared infrastructure where untrusted users may obtain local access. Although the vulnerability cannot be exploited remotely by itself, it becomes particularly valuable after an attacker gains an initial foothold through another vulnerability or stolen credentials.
Administrators should also strengthen file integrity monitoring for privileged system files and ensure endpoint detection platforms monitor unexpected changes to authentication databases and SUID binaries. Finally, organizations should verify that patched kernels are actively running after maintenance windows, as installing updates without rebooting leaves vulnerable kernels in memory.
RefluXFS serves as another reminder that modern privilege escalation vulnerabilities increasingly emerge from subtle logic errors rather than classic memory corruption. As Linux filesystems continue to incorporate advanced storage optimizations such as reflinks and copy-on-write, ensuring synchronization correctness becomes just as important as preventing traditional buffer overflows. In this case, a brief lock-drop window in XFS proved sufficient to undermine one of the operating system’s fundamental security assumptions: that an unprivileged user cannot modify protected system files.
