CVE-2026-64600

High [CVE-2026-64600] XFS data corruption using reflink

CVE-2026-64600Source published Jul 14, 2026Source updated Jul 14, 2026

In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data…

Affected products in this advisory

• Red Hat Enterprise Linux 10.0 Extended Update Support
• Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support
• Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On
• Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support

8 more entries in the full advisory.

Source-reported affected versions

Affected-version details not available in this record.

Source-reported fixed versions

• kernel-0:6.12.0-211.34.1.el10_2
• kpatch-patch
• kernel-0:6.12.0-55.89.1.el10_0
• kernel-rt-0:4.18.0-553.144.1.rt7.485.el8_10

26 more entries in the full advisory.

Mitigation guidance

• 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: 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.