Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

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

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.

Timeline

  1. ID reserved

    By Linux

  2. · 28 days later

    Published

  3. · 1 day later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-98975, by who scored it
Scored byCVSSScoreVector
LinuxCNA (assigner)3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
NVDNVD · Received3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS (exploitation in 30 days)
0.16% · top 94% of all CVEs (13 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.

Affected products

  • Linux · Linux

    • affected f0bc4d134b46607967bda1205ce3226a1bd95f42 – < 1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be
    • affected f0bc4d134b46607967bda1205ce3226a1bd95f42 – < 7d3b9b2c9dc57f93f36c716ab752548cb4db9900
    • affected f0bc4d134b46607967bda1205ce3226a1bd95f42 – < 4756c94260e69ce42612b8220c3614f02f7a11d5
    • affected f0bc4d134b46607967bda1205ce3226a1bd95f42 – < d84d6c1a7f1e2de9e601703a326a4c1b7b421943
  • Linux · Linux

    • affected 4.9
    • unaffected < 4.9
    • unaffected 6.12.114 – ≤ 6.12.*
    • unaffected 6.18.57 – ≤ 6.18.*
    • unaffected 7.2.11 – ≤ 7.2.*
    • unaffected 7.3 – ≤ *

References

References4

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-98975 badge
[![CVE-2026-98975](https://cveledger.app/badge/CVE-2026-98975.svg)](https://cveledger.app/cve/CVE-2026-98975)

Record last updated .