High [CVE-2026-64600] XFS data corruption using reflink
This high-severity Red Hat Linux advisory covers CVE-2026-64600 affecting 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.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Summary
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 fork mapping if the sequence counter changes across the ILOCK cycle.
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. If properly exploited this vulnerability may lead to privilege escalations or arbitrary code execution.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.
Official advisory · high-confidence parse· fetched 15 days ago·verify at source
- 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
- kernel-0:4.18.0-553.144.1.el8_10
- kernel-0:4.18.0-305.198.1.el8_4
- kernel-0:4.18.0-372.202.1.el8_6
- kernel-0:4.18.0-477.154.1.el8_8
- kernel-0:5.14.0-687.26.1.el9_8
- kernel-0:5.14.0-284.182.1.el9_2
- kernel-0:5.14.0-427.138.1.el9_4
- kernel-0:5.14.0-570.128.1.el9_6
- RHSA-2026:39494
- RHSA-2026:46951
- RHSA-2026:41062
- RHSA-2026:39180
- RHSA-2026:39179
- RHSA-2026:47998
- RHSA-2026:39984
- RHBA-2026:41254
- RHSA-2026:41229
- RHSA-2026:48016
- RHBA-2026:39332
- RHSA-2026:47981
- RHBA-2026:41013
- RHSA-2026:47997
- RHSA-2026:41063
- RHSA-2026:47984
- RHSA-2026:40425
- RHSA-2026:47983
Official advisory · high-confidence parse· fetched 15 days ago·verify at source
Mitigation checklist
- 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.
Official advisory · high-confidence parse· fetched 15 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.