{"cve":"CVE-2026-98975","nvd":{"published":"2026-10-23T13:17:19.157","modified":"2026-10-24T14:16:50.093","status":"Received","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: stop exchanging reflink flags when exchanging mappings\n\nWhen an exchange covers both files from offset 0 to i_disk_size,\nxmi_can_exchange_reflink_flags() assumes every mapping moved and hands\nthe reflink flag over to the other file.\n\nThat assumption is wrong.  A file can still own shared blocks past\ni_disk_size, e.g. after EXCHANGE_RANGE_TO_EOF sets a smaller size\nwithout unmapping anything.  The flag is cleared anyway, and the next\nwrite to such a block happens in place instead of CoW, corrupting the\nother file that shares it.\n\nCommit a23eca88448e (\"xfs: fix exchange-range reflink flag clearing\nissue with INO1_WRITTEN\") fixed one instance of this.  Rather than add\nanother special case, stop moving the flags.\nxfs_exchmaps_ensure_reflink() already sets the flag on both inodes\nbefore the exchange, so both just keep it.\n\nNothing sets CLEAR_INO{1,2}_REFLINK anymore.  Intents logged by older\nkernels may still carry them; recovery already masks them off, so they\nstay in the log format mask and are ignored.\n\nXFS_IOC_SWAPEXT has the same problem: it moves the reflink flag from\none inode to the other along with the extents.  Just removing that is\nnot enough here: the exchange path flags both inodes up front in\nxfs_exchmaps_ensure_reflink(), but swapext has no such step, so the\ninode receiving the shared extents would be left without the flag.\nSet it on both inodes instead, and make sure both have a CoW fork,\nsince an inode with the reflink flag is expected to have one.\n\nThe flag now stays until FALLOC_FL_UNSHARE_RANGE, xfs_scrub, or a\ntruncate to zero removes it.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":7.8},"cwes":[],"references":["https://git.kernel.org/stable/c/1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be","https://git.kernel.org/stable/c/4756c94260e69ce42612b8220c3614f02f7a11d5","https://git.kernel.org/stable/c/7d3b9b2c9dc57f93f36c716ab752548cb4db9900","https://git.kernel.org/stable/c/d84d6c1a7f1e2de9e601703a326a4c1b7b421943"],"products":[],"source":"nvd","synced_at":"2026-10-24T16:53:35.584907681+00:00"},"epss":{"cve":"CVE-2026-98975","score":0.00163,"percentile":0.0548,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}