Linux kernel XFS: Reflink flag handling in exchange-range can corrupt shared data
Summary
The XFS file system in the Linux kernel clears the reflink flag during exchange-range operations even when a file still owns shared blocks beyond its on-disk size. A local user or process with write access to such files can then write to shared blocks in place instead of copy-on-write, which modifies the other file that shares these blocks. The attack requires local access with low privileges on a host that uses reflink-enabled XFS.
Affected
- Linux kernel XFS code from commit f0bc4d134b46607967bda1205ce3226a1bd95f42 up to the fix commits listed in the sources
- Stable branches 6.12 before 6.12.114, 6.18 before 6.18.57, 7.2 before 7.2.11
- Exact fixed versions for distributions: Unknown.
Fixed in
- Linux kernel 6.12.114, 6.18.57 and 7.2.11 (per OSV and the CNA data)
- Fix commits: 1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be, 4756c94260e69ce42612b8220c3614f02f7a11d5, 7d3b9b2c9dc57f93f36c716ab752548cb4db9900, d84d6c1a7f1e2de9e601703a326a4c1b7b421943
- Distribution kernel versions: Unknown, check the distribution advisory.
Workaround
- No vendor workaround known.
- Restrict local shell and file access on hosts holding reflink-enabled XFS data.
- Restrict use of XFS_IOC_SWAPEXT to trusted users.
Exploitation
- No evidence of exploitation in the wild found.
- No CISA KEV entry found.
- No public proof of concept confirmed.
- EPSS was 0.00163 in one aggregator listing.
Our recommendation
- Apply the distribution kernel update in the regular patch cycle and prioritise multi-user or shared Linux hosts.
- Check whether your hosts use XFS with reflink and whether untrusted local users or containers run on them.
- Restrict local access and monitor for unexpected changes to shared file data.
- Verify the fixed version with your distribution's security advisory.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- CVE Record CVE-2026-98975 ubuntu.com
- Kernel fix commit 1fa2f3a7 git.kernel.org
- Kernel fix commit 4756c942 git.kernel.org
- Kernel fix commit 7d3b9b2c git.kernel.org
- Kernel fix commit d84d6c1a git.kernel.org
- OSV entry CVE-2026-98975 vulners.com
- NVD entry CVE-2026-98975 vulners.com
- Bell-SW Alpaquita OSV entry osv.dev
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 22:36.
Original description (NVD)
In the Linux kernel, the following vulnerability has been resolved: xfs: stop exchanging reflink flags when exchanging mappings When an exchange covers both files from offset 0 to i_disk_size, xmi_can_exchange_reflink_flags() assumes every mapping moved and hands the reflink flag over to the other file. That assumption is wrong. A file can still own shared blocks past i_disk_size, e.g. after EXCHANGE_RANGE_TO_EOF sets a smaller size without unmapping anything. The flag is cleared anyway, and the next write to such a block happens in place instead of CoW, corrupting the other file that shares it. Commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") fixed one instance of this. Rather than add another special case, stop moving the flags. xfs_exchmaps_ensure_reflink() already sets the flag on both inodes before the exchange, so both just keep it. Nothing sets CLEAR_INO{1,2}_REFLINK anymore. Intents logged by older kernels may still carry them; recovery already masks them off, so they stay in the log format mask and are ignored. XFS_IOC_SWAPEXT has the same problem: it moves the reflink flag from one inode to the other along with the extents. Just removing that is not enough here: the exchange path flags both inodes up front in xfs_exchmaps_ensure_reflink(), but swapext has no such step, so the inode receiving the shared extents would be left without the flag. Set it on both inodes instead, and make sure both have a CoW fork, since an inode with the reflink flag is expected to have one. The flag now stays until FALLOC_FL_UNSHARE_RANGE, xfs_scrub, or a truncate to zero removes it.
NVD references (4)
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.