Nine-Year-Old RefluXFS Linux Flaw Gives Local Users Root on Default RHEL Installs

Severity

Medium

A newly disclosed Linux kernel vulnerability, tracked as CVE-2026-64600 and nicknamed RefluXFS, allows an unprivileged local attacker to overwrite root-owned files on affected XFS filesystems, potentially leading to persistent root privilege escalation. The vulnerability affects Linux kernels 4.11 and later that use XFS with reflink enabled (reflink=1).

The issue primarily impacts default installations of Red Hat Enterprise Linux (RHEL) and its derivatives, including CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux 8/9/10, Fedora Server 31 and later, and Amazon Linux 2023 as well as Amazon Linux 2 images released from December 2022 onward. Systems running RHEL 7 are not affected because they predate XFS reflink support. Debian, Ubuntu, SLES, and openSUSE are generally unaffected unless administrators manually configured the root filesystem to use XFS with reflink enabled.

Successful exploitation requires the following conditions:

The system is running an unpatched Linux kernel version 4.11 or later.
The XFS filesystem was created with reflink=1.
The target file and an attacker-writable directory reside on the same XFS filesystem.

Because the overwrite occurs at the block layer, modified files retain their original ownership, permissions, timestamps, and setuid attributes, allowing malicious changes to persist even after a system reboot. Qualys demonstrated successful attacks against /etc/passwd and setuid-root binaries, with exploitation typically completing in under ten seconds.

How?

The vulnerability stems from a race condition in XFS’s reflink copy-on-write (CoW) implementation. An attacker first creates a reflink clone of a readable root-owned file using the FICLONE operation, which only requires read permission.

During concurrent O_DIRECT write operations, the Linux kernel temporarily releases the inode lock while reserving transaction space. During this window, another write operation may complete the copy-on-write process and remap the cloned file to a new storage block. However, when the first operation resumes, it continues using the outdated block mapping captured before the lock was released.

As a result, data intended for the attacker’s cloned file is mistakenly written into the original protected file. Since the write bypasses the page cache and directly modifies disk blocks, the target file’s metadata remains unchanged, making the modification difficult to detect through ownership, timestamps, or permission changes.

The upstream fix addresses this race by validating whether the file mapping has changed after the lock is reacquired. If the mapping has been modified, the kernel refreshes the block mapping before continuing the write operation, preventing stale mappings from being used.

Recommendations

Organizations should immediately install the latest kernel updates provided by their Linux distribution vendor and reboot affected systems to ensure the patched kernel is running, as installing the update alone does not replace the active kernel in memory.

Priority should be given to multi-user and multi-tenant systems where untrusted users, applications, CI/CD jobs, or containerized workloads can execute local code. Administrators should verify whether XFS filesystems have reflink enabled using xfs_info / | grep reflink= and identify systems meeting the exploitation requirements. As no practical workaround currently exists, organizations should rely on timely patching and rebooting. Existing security mechanisms such as SELinux, seccomp, kernel lockdown, and container isolation do not prevent exploitation of this vulnerability. Regular vulnerability management and prompt deployment of vendor security advisories remain the most effective defenses against RefluXFS.

Source

https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html