CVE-2026-64600

A flaw was found in the XFS filesystem. A race condition in the copy-on-write mechanism for reflinked files can cause writes to bypass the copy-on-write process and modify shared data blocks directly. As a result, data intended for a private copy may be written to the original shared location, corrupting the contents of other files that reference those blocks. A local attacker with read access to a file on an XFS filesystem with reflink enabled could exploit this flaw to corrupt files they do not have write access to, allowing content to be added to the target file. If properly exploited this vulnerability may lead to privilege escalations or arbitrary code execution.

This vulnerability can be mitigated using a SystemTap script. To create and apply the mitigation, follow the steps below:

1. Install and configure SystemTap

Install the SystemTap package and its dependencies following the instructions at:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap

2. Create the mitigation script

Create a file named `refluxfs_mitigation.stp` with the following contents:

probe begin {
        printf("refluxfs mitigation loaded\n")
}

probe module("xfs").function("xfs_file_remap_range").call {
        $remap_flags = 0xffff
}

probe module("xfs").function("xfs_file_remap_range").return {
        $return = -95
}

probe end {
        printf("refluxfs mitigation unloaded\n")
}

3. Load the mitigation

As the `root` user, execute SystemTap in guru mode:

stap -g refluxfs_mitigation.stp

Once the script is compiled and loaded, the following message will appear:

refluxfs mitigation loaded

With the mitigation active, any application attempting to use reflink to copy files will receive `-EOPNOTSUPP` (`-95`) when calling the `FICLONE` ioctl (or its variants) or the `copy_file_range()` syscall.

Important considerations:

1. SystemTap scripts are compiled into kernel modules. On systems with Secure Boot enabled, the kernel is in lockdown mode and will only load modules signed with a valid Secure Boot key or a key enrolled in the MOK. SystemTap can sign the generated module at compile time, but the user is responsible for key management. For instructions, refer to the "Sign a SystemTap module" section of:
This content is not included.https://www.redhat.com/en/blog/secure-boot-systemtap

2. The SystemTap module is not persistent across reboots. If the machine is restarted or the `stap` process is terminated, the module will be unloaded and the mitigation must be reapplied.

3. Programs that rely on CoW/reflink without a fallback mechanism may fail, as reflink operations will be unavailable on any XFS filesystem while the mitigation is loaded. This includes the `cp` command when run with `--reflink=always`. In that case, use `--reflink=auto` instead, which is the default behavior in Red Hat Enterprise Linux.