RefluXFS Linux Kernel Vulnerability Lets Local Attackers Gain Root Access

A Linux kernel vulnerability called RefluXFS allows an unprivileged local user to overwrite protected files on affected XFS filesystems and gain root access. The flaw, tracked as CVE-2026-64600, affects systems using vulnerable kernels and XFS filesystems with reflink support enabled.

The Qualys Threat Research Unit discovered the race condition in the XFS copy-on-write path. Researchers demonstrated that an ordinary user could modify files such as /etc/passwd or a setuid-root executable and then obtain full root privileges.

RefluXFS requires local access, so attackers cannot exploit it directly over a network. However, it can turn a limited account, compromised application, or restricted shell into complete control of the host. The resulting file changes persist after a reboot.

What is CVE-2026-64600?

Category	Details
Vulnerability	Race condition in the Linux kernel XFS copy-on-write path
CVE	CVE-2026-64600
Attack type	Local privilege escalation
Required access	An unprivileged local account or local code execution
Affected kernels	Linux 4.11 and later without the security fix
Required filesystem	XFS with reflink=1
Potential impact	Protected file overwrite and root access
Upstream fix	Linux commit 2f4acd0, merged on July 16, 2026

The flaw entered the Linux kernel in 2017 with code supporting direct I/O copy-on-write allocation. According to the detailed RefluXFS security advisory, the vulnerable code appeared in Linux 4.11 and remained in later mainline and stable kernels until maintainers developed a fix.

Not every Linux computer running kernel 4.11 or later remains exposed. The system must use an XFS filesystem created with reflink support, and the attacker needs a writable location on the same filesystem as a valuable readable target.

How the RefluXFS attack works

XFS reflinks allow two files to share the same physical disk blocks. When an application changes one file, the filesystem should allocate a private block for the new data. This copy-on-write process prevents the change from affecting the original file.

RefluXFS breaks that separation through two concurrent O_DIRECT writes to an attacker-controlled reflink clone. While preparing a copy-on-write transaction, XFS temporarily releases an inode lock so it can wait for transaction log space.

A second writer can complete its operation during this window and remap the cloned file. When the first writer resumes, it can rely on an outdated physical block mapping and write attacker-controlled data into the block that still belongs to the protected source file.

Why exploitation can provide root privileges

The attack operates on disk blocks rather than through a normal write to the protected file. As a result, ordinary file permission checks do not prevent the final block-level modification.

Qualys demonstrated the attack by reflink-cloning a readable system file into a writable location and racing multiple direct writes against the clone. Its technical disclosure describes tests that changed the root entry in /etc/passwd, allowing the attacker to open a root shell without a password.

The researchers also tested setuid-root binaries as potential targets. Since the attack changes data below the inode metadata layer, the targeted file can retain its owner, permissions, and setuid bit after its contents change.

• The attacker must already have local code execution.
• The target file must be readable and reside on the affected XFS filesystem.
• The attacker needs a writable directory on that same filesystem.
• The filesystem must have reflink support enabled.
• The running kernel must lack the RefluXFS fix.

Which Linux distributions may be affected?

Default installations of several enterprise Linux distributions commonly use XFS for the root filesystem. The affected group includes supported versions of Red Hat Enterprise Linux, CentOS Stream, Rocky Linux, AlmaLinux, Oracle Linux, CloudLinux, Amazon Linux, and Fedora Server, depending on the installed kernel and filesystem configuration.

Debian, Ubuntu, SUSE Linux Enterprise Server, openSUSE, Arch Linux, and Fedora Workstation generally do not use XFS as their default root filesystem. Administrators can still expose these systems if they manually create or select an XFS filesystem with reflink=1.

RHEL and CentOS 7 do not meet the kernel and filesystem requirements described by the researchers. Their older kernels predate XFS reflink support. An in-place upgrade from RHEL 7 may also retain a filesystem created without reflinks, although administrators should verify the actual configuration.

Distribution or platform	Typical exposure
RHEL 8, 9, and 10	Potentially exposed on default reflink-enabled XFS installations
CentOS Stream 8, 9, and 10	Potentially exposed
Rocky Linux, AlmaLinux, Oracle Linux, and CloudLinux 8 to 10	Potentially exposed
Amazon Linux 2023	Potentially exposed
Amazon Linux 2 AMIs from December 2022 onward	Potentially exposed
Fedora Server 31 and later	Potentially exposed
Debian, Ubuntu, SUSE, Arch, and Fedora Workstation	Usually unaffected by default, but exposed when configured with suitable XFS volumes

How to check for RefluXFS exposure

Administrators can check whether the root filesystem uses XFS reflinks by running the following command:

xfs_info / | grep reflink=

An output containing reflink=1 confirms that the filesystem supports reflinks. An output of reflink=0 means the RefluXFS attack path does not apply to that filesystem. If xfs_info returns an error, the selected mount point may not use XFS.

Administrators should repeat the check for every mounted XFS filesystem. The CloudLinux security guidance notes that reflink support forms part of the XFS superblock and cannot be disabled later through a mount option or sysctl setting.

1. Identify every mounted XFS filesystem.
2. Check each filesystem for reflink=1.
3. Record the active kernel version with uname -r.
4. Compare that version with the fixed package listed by the distribution vendor.
5. Install the security update and confirm that the fixed kernel runs afterward.

SELinux and kernel hardening do not stop the attack

Qualys successfully exploited the vulnerability on a system running SELinux in Enforcing mode. SELinux controls access through security policies, but RefluXFS abuses valid filesystem operations before redirecting the final write at the block layer.

Protections such as KASLR, SMEP, SMAP, hardened memory allocators, and kernel lockdown address different attack techniques. They do not correct the stale XFS block mapping that causes this vulnerability.

Container restrictions may reduce an attacker’s access to the host filesystem, but administrators should not treat containers as a universal mitigation. A container or hosted workload that can reach a vulnerable reflink-enabled XFS volume may still create risk, depending on its mounts and permissions.

Researchers used AI to accelerate the discovery

Qualys found RefluXFS during a research project with Anthropic. Researchers asked a preview model called Claude Mythos to search the Linux kernel for a race condition resembling Dirty COW, then narrowed the review to filesystem code.

The model identified the suspicious XFS path and produced an initial proof of concept. Human researchers reviewed the reasoning, reproduced the exploit, verified the technical claims, and coordinated disclosure with XFS and Linux kernel maintainers.

The Qualys analysis estimates that more than 16.4 million systems could meet the broad exposure criteria. This number comes from the company’s asset-management data and should not be treated as a confirmed count of exploitable hosts.

How administrators should fix CVE-2026-64600

The upstream fix resamples the XFS data-fork mapping after the kernel releases and reacquires the inode lock. Linux maintainers merged the correction into the source tree on July 16, 2026, before the coordinated public disclosure on July 22.

Administrators should install the kernel package supplied by their Linux distributor instead of relying only on the upstream version number. Enterprise vendors often backport security fixes without changing their kernels to the latest mainline release.

After a conventional kernel package update, reboot the machine and verify the active version with uname -r. The CloudLinux remediation notice also documents fixed packages and a vendor-supported live-patching path for eligible customers.

• Prioritize shared hosting, build servers, development systems, and multi-user machines.
• Patch systems where untrusted workloads can execute local code.
• Check cloud images and templates before launching new instances.
• Reboot systems after normal kernel updates.
• Verify the active kernel rather than checking only installed packages.
• Use a live patch only when the distribution vendor explicitly supports it for this CVE.

RefluXFS does not produce the kernel warnings or crashes often associated with kernel exploitation. Security teams should therefore focus on exposure discovery, patch status, unexpected changes to sensitive files, and suspicious local privilege escalation activity instead of relying only on kernel logs.

FAQ