Skip to content
Heist/ feed
Back to feed
HighFix available

xfs: stop exchanging reflink flags when exchanging mappings

Type: advisorySources: OSV

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

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.114, 6.18.57, 7.2.11
CVEs
CVE-2026-98975
Confirmed fixed CVEs
Not specified
Updated in this feed
5 Nov 2026, 10:13 UTC · Revision 1

Source evidence

xfs: stop exchanging reflink flags when exchanging mappings

core-osv · Original source

Published 23 Oct 2026, 12:19 UTC

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

osv:CVE-2026-98975

Kernel

Fixed versions: 6.12.114, 6.18.57, 7.2.11

Complete source record
{
  "id": "1f63bcd8c72def3c2ff41bc7e898041acbcc43cf51f17923b7eadc5581d0ccdc",
  "url": "https://osv.dev/vulnerability/CVE-2026-98975",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "xfs: stop exchanging reflink flags when exchanging mappings",
    "summary": "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",
    "evidence": "osv:CVE-2026-98975",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.114",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.57",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.2.11",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-98975",
      "aliases": [
        "CVE-2026-98975"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "f0bc4d134b46607967bda1205ce3226a1bd95f42"
                },
                {
                  "fixed": "1fa2f3a7ef7ee0f2503a4b0afe24bc8c9d0820be"
                },
                {
                  "fixed": "7d3b9b2c9dc57f93f36c716ab752548cb4db9900"
                },
                {
                  "fixed": "4756c94260e69ce42612b8220c3614f02f7a11d5"
                },
                {
                  "fixed": "d84d6c1a7f1e2de9e601703a326a4c1b7b421943"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98975.json"
          }
        },
        {
          "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"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98975.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:43.727276263Z",
      "provider": "osv",
      "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",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98975.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-98975",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98975.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-98975",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 511588,
  "published_at": "2026-10-23T12:19:48.379+00:00"
}