RefluXFS: A Linux Kernel Vulnerability Exposes XFS Filesystems to Root Privilege Escalation

A critical security vulnerability, dubbed RefluXFS and identified as CVE-2026-64600, has been disclosed, posing a significant risk to Linux systems utilizing the XFS filesystem. This flaw allows an unprivileged local user to overwrite root-owned files, a capability that can lead to persistent root access and complete system compromise. The vulnerability, discovered and reported by cybersecurity firm Qualys, leverages a race condition within the XFS filesystem’s reflink functionality, a feature that enables efficient data deduplication by creating copy-on-write (COW) clones of files.

The implications of RefluXFS are far-reaching, particularly for default installations of popular Linux distributions such as Red Hat Enterprise Linux and its derivatives, Fedora Server, and Amazon Linux. These systems, when configured with XFS and reflink support, become susceptible to exploitation. Qualys has demonstrated that the vulnerability can be used to overwrite critical system files like /etc/passwd, which contains user account information, and setuid-root binaries, executables that run with root privileges. The exploit’s insidious nature lies in its ability to bypass standard file ownership and permission checks, ensuring that modified setuid-root binaries continue to execute as root even after a system reboot.

Timeline of Discovery and Patching

The timeline of RefluXFS’s discovery and remediation highlights the rapid pace of modern cybersecurity threats and the collaborative efforts involved in addressing them. The root cause of the vulnerability was traced back to Linux kernel version 4.11, released in 2017, indicating a long-standing flaw that has only recently been identified. The fix for CVE-2026-64600 was merged into the Linux kernel development tree on July 16, 2026, a mere six days before its public disclosure on July 22, 2026. This swift patching demonstrates the responsiveness of the Linux kernel community to critical security issues.

Following the merge, Linux vendors have begun the process of backporting the fix to their respective stable kernel branches. Red Hat, a key player in the Linux ecosystem, was among the first to issue advisories and patches. On July 14, 2026, eight days prior to the public disclosure, Red Hat began distributing kernel advisories (RHSA-2026:39179, RHSA-2026:39180 for RHEL 8, and RHSA-2026:39494 for RHEL 10), ensuring that systems that regularly update their security packages were protected even before the vulnerability had a formal designation. This proactive approach underscores Red Hat’s commitment to security and its ability to identify and address potential threats rapidly.

Other distributions are also in the process of integrating the fix. As of July 23, 2026, Debian’s security tracker indicated that the patch was included in their Trixie distribution with kernel version 6.12.96-1 and in the unstable branch with kernel 7.1.4-1. However, older stable branches like Bookworm and Bullseye, including their security updates, remained marked as vulnerable. This highlights the importance for users to confirm that their specific distribution and kernel version have received the necessary update.

The Mechanics of RefluXFS: A Deep Dive into the Race Condition

The RefluXFS vulnerability exploits a subtle but critical flaw in the XFS filesystem’s handling of the FICLONE operation, which is used to create file clones. The core of the exploit involves a race condition that occurs during concurrent write operations on a cloned file.

Here’s a breakdown of the exploitation process:

1. File Cloning with FICLONE: An attacker, with only read access to a root-owned file, initiates a clone operation using FICLONE. This creates a new file (the "scratch file") that initially shares the same physical disk blocks as the original root-owned file. This is made possible by XFS’s reflink feature, which employs a copy-on-write (COW) mechanism. Until a write operation occurs, both files point to the identical data on disk, making it efficient for storage.

2. Concurrent O_DIRECT Writes: The attacker then initiates concurrent O_DIRECT write operations against the cloned file. O_DIRECT is a flag that bypasses the operating system’s page cache, allowing direct read and write operations to and from block devices. This bypass is crucial for the exploit, as it skips normal kernel revalidation hooks that might otherwise detect the inconsistency.

3. The Race Window: The vulnerability emerges during the process where the kernel reads the data-fork mapping of the file under an inode lock (ILOCK). This operation is handed to the xfs_reflink_fill_cow_hole() function. To manage the COW operation, this function temporarily releases the ILOCK to reserve space in the filesystem’s transaction log.

4. The Stale Mapping: It is during this brief window, when the ILOCK is released, that a second writer can complete its COW operation. This second writer effectively re-maps the cloned file to a new set of disk blocks. When the first writer reacquires the ILOCK, it refreshes its understanding of the file’s data-fork mapping. However, the critical issue is that it continues to use the stale address it captured before the lock was released.

5. Overwriting Root-Owned Data: Because the first writer’s operation is now operating on a stale address that points to a block that the filesystem no longer considers shared (as it has been remapped by the second writer), XFS perceives this block as unallocated or free to be overwritten. Consequently, the data intended for the attacker’s cloned file is instead written directly into the original, root-owned file.

The upstream patch, described in commit 2f4acd0f2eab45690ec2c08c80b6ef2e7, directly addresses this by ensuring that the data-fork mapping is re-read after the ILOCK is reacquired if the if_seq counter has changed. This prevents the use of stale mapping information. The patch also touches xfs_reflink_fill_delalloc(), which exhibits a similar lock-cycle pattern and was not initially highlighted by Qualys but may also be susceptible to related issues.

Vulnerable Systems and Conditions for Exploitation

Exploiting RefluXFS requires the fulfillment of three specific conditions:

• XFS Filesystem with Reflink Support: The target system must be using the XFS filesystem and have the reflink feature enabled. This is the foundational requirement.
• Untrusted Code Execution: An unprivileged local user must be able to execute code on the system. This could be through a compromised service, a malicious script, a shell login, or even within a CI/CD pipeline.
• Shared Filesystem with Attacker-Writable Directory: The vulnerable root-owned file and the attacker-writable directory must reside on the same XFS filesystem that has reflink support enabled.

Qualys specifically identifies the following default installations as being susceptible:

• Red Hat Enterprise Linux (RHEL) and Derivatives: RHEL 8, 9, and 10, as well as CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, and CloudLinux 8, 9, and 10. It’s important to note that RHEL 7 systems are generally not affected because their XFS implementations predate the widespread adoption of reflink support.
• Fedora Server: Versions 31 and later.
• Amazon Linux: Amazon Linux 2023 and Amazon Linux 2 images released from December 2022 onwards.

Distributions like Debian, Ubuntu, SUSE Linux Enterprise Server (SLES), and openSUSE are less likely to be affected by default, as they typically do not use XFS as their root filesystem. However, if an administrator manually configured these systems with XFS and enabled reflinks during installation, they would also be exposed.

To check if a system’s root filesystem meets the reflink condition, administrators can use the following command:

xfs_info / | grep reflink=

If the output is reflink=1, it indicates that condition two is met. A similar check should be performed on any other mounted XFS volumes where protected files and attacker-writable directories might coexist.

Implications and Broader Context

The discovery of RefluXFS underscores several critical trends in the cybersecurity landscape. Firstly, it highlights the persistent threat of privilege escalation vulnerabilities in the Linux kernel, a cornerstone of modern computing infrastructure. The fact that this flaw existed since 2017, despite rigorous kernel development, speaks to the complexity of low-level systems programming and the challenges in uncovering deeply embedded bugs.

Secondly, the role of Artificial Intelligence in vulnerability discovery is becoming increasingly prominent. Qualys credits an AI model, specifically Anthropic’s Claude Mythos Preview, with finding RefluXFS. The AI was prompted to search for vulnerabilities similar to the infamous Dirty COW exploit, and it not only located the race condition but also generated a working root exploit and drafted the initial advisory. This marks a significant advancement in the application of AI for cybersecurity research, potentially accelerating the identification of threats but also raising questions about the ethical implications and the potential for misuse.

This incident is not an isolated event for Qualys. The company has recently disclosed other significant kernel vulnerabilities, including a snap-confine flaw in Ubuntu Desktop (CVE-2026-8933) that allowed local users to gain root access, and a nine-year-old bug in the kernel’s ptrace checks. This pattern suggests a broader trend of older, yet critical, vulnerabilities being unearthed, possibly due to more sophisticated analysis tools and techniques, including AI.

Mitigation and Remediation: Patch, Then Reboot

The primary and most effective mitigation for RefluXFS is to apply the vendor-provided kernel patches. As mentioned, Red Hat has already released advisories for its RHEL 8, 9, and 10 streams. Users are strongly advised to:

1. Identify Affected Systems: Determine if your Linux distribution and its XFS filesystem configuration meet the conditions for exploitation.
2. Apply Vendor Updates: Install the relevant kernel security updates from your distribution’s official repositories. Confirm that the advisory specifically addresses CVE-2026-64600 for your exact release.
3. Reboot Systems: Crucially, applying a kernel update does not take effect until the system is rebooted. The running kernel in memory must be replaced by the patched version. After applying the update, a full system reboot is mandatory to ensure the fix is active.
4. Verify Kernel Version: After rebooting, verify that the system is running the updated, patched kernel version.

It is important to note that there is no simple mount option or sysctl setting that can disable XFS reflinks after a filesystem has been created. Furthermore, Qualys’s testing indicated that common security measures such as SELinux in enforcing mode, seccomp, kernel lockdown, and container boundaries failed to prevent exploitation. Memory protection mechanisms like KASLR and SMEP are also ineffective against this vulnerability, as it operates at the block layer rather than directly corrupting memory.

One potential, albeit limited, mitigating factor is that the race condition only triggers if the target block on the original file is in an "unshared" state. This means that if an administrator has already reflink-copied a file, it might not be susceptible to overwriting via this exploit. Similarly, setuid-root binaries are generally not reflinked, reducing their immediate risk. However, these are not considered reliable security measures and should not replace patching.

As of the initial disclosure, no exploitation in the wild had been reported. However, the existence of a working proof-of-concept exploit, published on the oss-security mailing list, underscores the urgency of patching.

The RefluXFS vulnerability serves as a stark reminder of the continuous need for vigilance in system security. While the Linux kernel is known for its robustness and security, the discovery of such deep-seated flaws emphasizes the ongoing challenge of maintaining a secure computing environment. The collaboration between researchers, AI, and the open-source community is vital in identifying and rectifying these threats before they can be widely exploited. Users and administrators are urged to act swiftly by applying the necessary patches and rebooting their systems to safeguard against this critical privilege escalation vulnerability.