Skip to main content
VulnerabilityPublished Updated

CVE-2026-98975: Linux kernel · xfs: stop exchanging reflink flags when exchanging mappings

Source GCVE Database

0
Authoritative record:CVE-2026-98975· High 7.8

Not known to be exploited · CVSS 7.8 High · fixed in d84d6c1a7f1e2de9e601703a326a4c1b7b421943 : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in d84d6c1a7f1e2de9e601703a326a4c1b7b421943, 4756c94260e69ce42612b8220c3614f02f7a11d5, 7d3b9b2c9dc57f93f36c716ab752548cb4db9900 +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 23 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to d84d6c1a7f1e2de9e601703a326a4c1b7b421943, 4756c94260e69ce42612b8220c3614f02f7a11d5, 7d3b9b2c9dc57f93f36c716ab752548cb4db9900 or 1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ f0bc4d134b46607967bda1205ce3226a1bd95f42, < d84d6c1a7f1e2de9e601703a326a4c1b7b421943
Fixed in
  • d84d6c1a7f1e2de9e601703a326a4c1b7b421943
LinuxLinuxAffected
  • ≥ f0bc4d134b46607967bda1205ce3226a1bd95f42, < 4756c94260e69ce42612b8220c3614f02f7a11d5
Fixed in
  • 4756c94260e69ce42612b8220c3614f02f7a11d5
LinuxLinuxAffected
  • ≥ f0bc4d134b46607967bda1205ce3226a1bd95f42, < 7d3b9b2c9dc57f93f36c716ab752548cb4db9900
Fixed in
  • 7d3b9b2c9dc57f93f36c716ab752548cb4db9900
LinuxLinuxAffected
  • ≥ f0bc4d134b46607967bda1205ce3226a1bd95f42, < 1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be
Fixed in
  • 1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be
LinuxLinuxAffected
  • =4.9
Fixed in–

Description

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.

References

Community reviews

Loading reviews…