CVE-2026-98975None▾ SunlitIn 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 e…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
Linux >= f0bc4d134b46607967bda1205ce3226a1bd95f42 < 1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820beLinux >= f0bc4d134b46607967bda1205ce3226a1bd95f42 < 7d3b9b2c9dc57f93f36c716ab752548cb4db9900Linux >= f0bc4d134b46607967bda1205ce3226a1bd95f42 < 4756c94260e69ce42612b8220c3614f02f7a11d5Linux >= f0bc4d134b46607967bda1205ce3226a1bd95f42 < d84d6c1a7f1e2de9e601703a326a4c1b7b421943Linux 4.9Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99001Nonedrm/xe/i2c: cancel the client work on remove
CVE-2026-98989Nonenamespace: check a recursive bind mount for mount namespace loops
CVE-2026-98988Nonenamespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
CVE-2026-98992Nonenamespace: don't copy an unmounted mount tree
CVE-2026-98991Nonenamespace: queue a mount only once for mount notifications
CVE-2026-98990Nonenamespace: check a submount for references right before unmounting it