RefluXFS: Critical Linux Kernel Flaw Allows Unprivileged Local Users to Gain Persistent Root Access on XFS Filesystems

A significant vulnerability in the Linux kernel, dubbed RefluXFS and tracked as CVE-2026-64600, was publicly disclosed on July 22, revealing a critical local privilege escalation (LPE) flaw that permits an unprivileged local user to overwrite root-owned files on XFS filesystems. This exploit can lead to persistent root access, posing a severe threat to affected systems. Security firm Qualys, which discovered the flaw, has confirmed that default installations of several major Linux distributions, including Red Hat Enterprise Linux (RHEL) and its derivatives, Fedora Server, and Amazon Linux, are particularly susceptible under specific conditions.

Technical Breakdown: Unraveling CVE-2026-64600

At its core, RefluXFS exploits a race condition within the XFS filesystem’s copy-on-write (CoW) mechanism, specifically when handling reflink operations and concurrent direct I/O writes. XFS is a high-performance journaling filesystem known for its scalability and advanced features, one of which is reflink. The reflink feature, introduced to XFS in Linux 4.9 and widely adopted since, allows for efficient cloning of files. Instead of copying data blocks, reflink creates a new inode that initially points to the same physical disk blocks as the original file. Data is only copied to new blocks (copy-on-write) when one of the files is modified. This process is transparent to the user and significantly saves disk space and I/O operations.

The vulnerability stems from a logical flaw in how the kernel manages block mappings during FICLONE operations, which are used to create reflinks, particularly when combined with O_DIRECT writes. An attacker can leverage this by cloning a root-owned file into a scratch file they control. While the initial FICLONE operation only requires read access to the source file, the subsequent race condition allows for illicit writes.

The Race Condition Explained: Stale Mappings

The exploit unfolds through a precise timing attack:

1. An attacker initiates a FICLONE operation to create a reflink copy of a root-owned target file (e.g., /etc/passwd or a setuid-root binary) into an attacker-controlled scratch file. Initially, both files share the same physical data blocks on the disk.
2. The kernel, in processing the FICLONE operation, reads the data-fork mapping under an inode lock. This mapping indicates which physical blocks belong to the file.
3. Critically, the kernel then cycles (releases and reacquires) this inode lock to reserve transaction space, a necessary step in the copy-on-write process.
4. During the brief window when the inode lock is released, a second, concurrent write operation (an O_DIRECT write initiated by the attacker to their scratch file) can complete its copy-on-write process. This operation correctly remaps the cloned file to a new, distinct block.
5. When the first writer (from the FICLONE operation) reacquires the lock, it refreshes the copy-on-write fork but mistakenly continues to use the old data-fork mapping it captured before the lock was released. This mapping is now "stale" because the cloned file’s blocks have been moved.
6. The stale address now points directly to a block still owned only by the original, protected root-owned file. XFS, unaware of the stale mapping due to the bypass of its normal inode and metadata checks, sees this block as unshared from the perspective of the O_DIRECT write to the attacker’s file. Consequently, it permits the direct write operation, causing data intended for the attacker’s scratch file to erroneously land in the original, root-owned target file.

The upstream patch explicitly describes this failure: "the mappings are stale as soon as we reacquire the ILOCK." Because O_DIRECT I/O bypasses the page cache and its revalidation hooks, the malicious write lands directly on disk without triggering any kernel warnings or log entries, making detection challenging. Qualys reported that in their testing, this race condition typically succeeded within ten seconds.

Exploitation Mechanism and Persistence

The impact of this block-layer overwrite is profound. The attack operates at such a low level that it leaves the target file’s metadata—ownership, permissions, timestamps, and crucially, the setuid bit—completely untouched. This means a modified setuid-root binary, even if its contents are corrupted or replaced by the attacker, will still execute with root privileges. Similarly, overwriting /etc/passwd can allow an attacker to strip the root password or add new root-privileged users, gaining persistent, undetected control over the system. The changes made at the block layer also survive system reboots, ensuring the persistence of the exploit.

Scope of Exposure: Who is Vulnerable?

Qualys’s advisory highlights that exploitation requires three specific conditions to be met on a system:

1. XFS Filesystem: The system must be using an XFS filesystem for the target files.
2. Reflink Enabled: The XFS filesystem must have the reflink feature enabled (reflink=1). This feature has been part of XFS since Linux 4.9, and enabled by default on newer XFS filesystems.
3. Local Untrusted Code Execution: An unprivileged local user must be able to run untrusted code on the system, whether through a shell, a Continuous Integration (CI) job, or a compromised service. Additionally, a protected file and an attacker-writable directory must share the same XFS volume.

Specific Distribution Impact

While the bug was introduced in Linux kernel 4.11 in 2017, its practical impact is largely on systems where XFS is commonly used as the default or primary filesystem, especially for root partitions.

• Highly Exposed Distributions: Default installations of Red Hat Enterprise Linux (RHEL), CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, and CloudLinux (versions 8, 9, and 10), Fedora Server (31 and later), Amazon Linux 2023, and Amazon Linux 2 images from December 2022 onward are identified as particularly vulnerable. RHEL 7 filesystems are generally not affected as they predate the widespread adoption and default enabling of XFS reflink support.
• Conditionally Exposed Distributions: Distributions like Debian, Ubuntu, SUSE Linux Enterprise Server (SLES), and openSUSE do not typically use XFS for the root filesystem by default. However, they become exposed if an administrator explicitly chose XFS with reflink enabled during installation or for other mounted volumes.

Checking for Vulnerability

System administrators can quickly check if their XFS filesystems have the reflink feature enabled using the xfs_info command:
xfs_info / | grep reflink=

If the output includes reflink=1, then the second condition for exploitation is met for the root filesystem. This check should also be performed on any other mounted XFS volumes where protected files and attacker-writable directories might coexist.

A Chronology of Discovery and Remediation

The journey of CVE-2026-64600 from its inception to public disclosure involves several key milestones, highlighting the collaborative nature of vulnerability research and remediation in the open-source world.

The Bug’s Origin and Patch Development

The flaw’s roots trace back to Linux kernel 4.11, released in 2017, as indicated by a Fixes: tag naming commit 3c68d44a2b49 and a stable backport request marked # v4.11. This means the vulnerability lay dormant and undetected in the kernel for approximately nine years, underscoring the complexity of kernel development and the subtle nature of race conditions.

The fix itself was merged into the upstream Linux kernel on July 16, 2026, just days before public disclosure. The patch, specifically commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7, addresses the stale mapping issue by introducing a mechanism to re-validate data fork mappings after an inode lock cycle. It modifies two helper functions, xfs_reflink_fill_cow_hole() and xfs_reflink_fill_delalloc(), which both exhibited the problematic lock-cycle pattern. The fix involves snapshotting ip->i_df.if_seq before the lock is dropped and then re-reading the data fork with xfs_bmapi_read() if the sequence counter indicates that the mapping has changed during the lock release period.

AI’s Role in Unearthing the Flaw

Perhaps one of the most remarkable aspects of RefluXFS’s discovery is the pivotal role played by artificial intelligence. Qualys researchers utilized "Claude Mythos Preview," Anthropic’s restricted-access frontier AI model, for vulnerability research. According to their technical advisory, they specifically "asked it to find a vulnerability similar to Dirty COW." Dirty COW (CVE-2016-5195) was another infamous Linux kernel LPE that exploited a race condition in the copy-on-write mechanism of the kernel’s memory management subsystem.

The AI model not only located the race condition in the XFS reflink implementation but also proceeded to write a working root exploit and draft the initial technical advisory. Qualys researchers then validated the AI’s findings by reproducing the exploit on a stock Fedora Server 44 installation, meticulously checking the model’s reasoning before coordinating disclosure with upstream kernel developers and affected Linux vendors. This marks a significant milestone in the application of AI for advanced cybersecurity research, demonstrating its potential to uncover deeply embedded and complex vulnerabilities that have eluded human researchers for years.

Coordinated Disclosure and Vendor Response

Following the upstream patch merge, a coordinated disclosure strategy was initiated. Linux vendors began shipping backported kernels containing the fix. The public disclosure by Qualys occurred on July 22, providing system administrators and security professionals with the necessary information to assess and mitigate their risks. This timeline emphasizes the importance of responsible disclosure practices, allowing vendors to prepare and release patches before the full technical details of a vulnerability are made public, thereby minimizing the window of exposure for users.

Vendor Reactions and Patching Efforts

The coordinated disclosure process ensured that major Linux distribution vendors were prepared to roll out updates promptly.

Red Hat’s Swift Action

Red Hat, given the significant impact on its Enterprise Linux ecosystem, issued "Important"-rated kernel advisories across affected RHEL 8, 9, and 10 streams. The errata began landing on July 14, a full eight days before the public disclosure. This proactive approach meant that customers who applied these updates on schedule were protected before the vulnerability was widely known. Specific advisories include RHSA-2026:39179 and RHSA-2026:39180 for RHEL 8, and RHSA-2026:39494 for RHEL 10, with extended-support and SAP streams following through July 17. Red Hat’s bug tracker, entry 2498915, initially described the issue as "kernel: XFS data corruption using reflink," indicating an early understanding of the underlying mechanism.

Debian’s Status

As of July 23, Debian’s security tracker listed the fix for CVE-2026-64600 in trixie-security (kernel 6.12.96-1) and unstable (kernel 7.1.4-1). However, trixie‘s base kernel 6.12.94-1 and forky‘s 7.1.3-1 were still marked vulnerable, as were the bookworm and bullseye releases, including their security branches. This highlights the varying speeds of patch deployment across different distribution release channels and the need for users to monitor their specific distribution’s security advisories.

Other Linux Distributions

Other distributions, particularly those based on RHEL (like AlmaLinux, Rocky Linux, Oracle Linux, CentOS Stream, and CloudLinux), were also expected to release patches in line with their upstream sources. Amazon Linux 2023 and Amazon Linux 2 (from December 2022 onwards) are also affected, requiring updates from Amazon. Users of any Linux distribution that utilizes XFS with reflink enabled are urged to consult their vendor’s security advisories and apply patches immediately.

Mitigation Challenges and Security Implications

RefluXFS presents a particularly challenging vulnerability due to the absence of practical workarounds and its ability to bypass common security mechanisms.

Absence of Workarounds

Qualys explicitly stated that no practical mitigation or temporary configuration change is available to disable XFS reflinks after a filesystem has been created. There is no mount option or sysctl parameter that can be used to mitigate the flaw without patching the kernel. This lack of a temporary fix elevates the urgency of applying the kernel update.

Bypassing Standard Protections

The firm’s testing confirmed that standard Linux security mechanisms, including SELinux in Enforcing mode, seccomp (secure computing mode), kernel lockdown, and container boundaries, all failed to prevent the exploitation of RefluXFS. This is because the vulnerability operates at the block layer, directly manipulating disk blocks, rather than exploiting memory corruption or traditional process-level access control issues that these mechanisms are designed to address. Memory protections such as KASLR (Kernel Address Space Layout Randomization) and SMEP (Supervisor Mode Execution Prevention) are also irrelevant, as the attack does not involve injecting or executing malicious code in kernel memory.

Impact on System Integrity

The ability for an unprivileged local user to achieve persistent root access is among the most severe categories of vulnerabilities. For systems operating in multi-tenant environments (e.g., cloud hosting, shared servers), where untrusted code or users might have local shell access, the risk is extremely high. Similarly, Continuous Integration/Continuous Deployment (CI/CD) pipelines or systems with compromised services that allow local code execution become prime targets. The ability to modify setuid-root binaries silently, without changing metadata or triggering logs, could allow attackers to establish backdoors that persist across reboots and go undetected for extended periods. While the race only fires if the target’s block starts unshared, Qualys noted that an unprivileged user can reset this condition (e.g., by running chsh), and setuid-root binaries are unlikely to have been reflinked in the first place, thus keeping them vulnerable.

Broader Context: The Evolving Threat Landscape

RefluXFS is not an isolated incident but rather part of a trend of deep-seated kernel vulnerabilities being uncovered, often through advanced research techniques.

Qualys’ Track Record

Qualys has a consistent track record of discovering aged kernel bugs. Just a day before RefluXFS’s disclosure, the firm revealed a snap-confine flaw in Ubuntu Desktop (CVE-2026-8933), involving two race conditions allowing local users to gain root on default installs. In May, they uncovered a nine-year-old bug in the kernel’s ptrace checks. These discoveries highlight the persistent challenge of maintaining security in complex software like the Linux kernel, where subtle flaws can remain hidden for years.

The Future of AI in Cybersecurity

The discovery of RefluXFS by an AI model represents a significant leap forward in vulnerability research. While human expertise remains crucial for validation and coordinated disclosure, AI’s ability to sift through vast codebases, identify complex patterns, and even generate exploits demonstrates a powerful new paradigm for offensive and defensive cybersecurity. As AI models become more sophisticated, they are likely to play an increasingly vital role in uncovering zero-day vulnerabilities and fortifying critical infrastructure.

Importance of Proactive Security

The fact that RefluXFS, a flaw introduced nearly a decade ago, remained undetected until now underscores the continuous need for rigorous security audits, proactive vulnerability scanning, and rapid patching strategies. Organizations must treat kernel updates with the highest priority, understanding that the core of their operating system is a prime target for attackers seeking deep system control.

Call to Action: Patching and Verification

Given the severity and implications of CVE-2026-64600, immediate action is required for all affected Linux systems. The primary and only effective mitigation is to apply the vendor-provided kernel updates. It is crucial to remember that simply installing the package does not replace the kernel already running in memory. Therefore, administrators must:

1. Apply the vendor update: Install the latest kernel packages from their distribution’s repositories.
2. Reboot the system: A system reboot is essential for the new kernel to take effect.
3. Verify the running kernel: After rebooting, confirm that the system is indeed running the fixed kernel version.

At the time of writing, none of the vendors tracking the flaw had reported exploitation in the wild. However, the public availability of technical details and the potential for a public proof-of-concept (given Qualys’s advisory detailed the race and exploitation steps) mean that the threat landscape could quickly evolve. Vigilance and timely action are paramount to protect systems from this potent local privilege escalation vulnerability.

Conclusion

RefluXFS (CVE-2026-64600) stands as a stark reminder of the enduring challenge of securing fundamental operating system components. This nine-year-old flaw, capable of granting persistent root access on widely used Linux distributions, highlights the critical importance of rigorous security research, particularly with the emerging capabilities of artificial intelligence. While the coordinated disclosure process has provided a window for remediation, the absence of practical workarounds and the flaw’s ability to bypass conventional security measures make immediate patching and system reboots an absolute imperative for maintaining the integrity and security of Linux environments globally. The cybersecurity community must remain vigilant, as the discovery of such long-standing, severe vulnerabilities is a testament to the continuous and evolving nature of the threat landscape.