{"id":"CVE-2026-98975","summary":"xfs: stop exchanging reflink flags when exchanging mappings","details":"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.","modified":"2026-10-26T02:32:07.887309799Z","published":"2026-10-23T12:19:48.379Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98975.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be"},{"type":"WEB","url":"https://git.kernel.org/stable/c/4756c94260e69ce42612b8220c3614f02f7a11d5"},{"type":"WEB","url":"https://git.kernel.org/stable/c/7d3b9b2c9dc57f93f36c716ab752548cb4db9900"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d84d6c1a7f1e2de9e601703a326a4c1b7b421943"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98975.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98975"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"f0bc4d134b46607967bda1205ce3226a1bd95f42"},{"fixed":"1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be"},{"fixed":"7d3b9b2c9dc57f93f36c716ab752548cb4db9900"},{"fixed":"4756c94260e69ce42612b8220c3614f02f7a11d5"},{"fixed":"d84d6c1a7f1e2de9e601703a326a4c1b7b421943"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98975.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.9.0"},{"fixed":"6.12.114"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.57"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.11"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98975.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}