CVE-2026-97547: xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix exchange-range reflink flag clearing issue with INO1WRITTEN
When exchanging two full-file ranges, xmicanexchangereflinkflags() 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 XFSEXCHMAPSINO1WRITTEN is set. xfsexchmapscanskipmapping() 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 XFSEXCHMAPSINO1WRITTEN 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested.
Linux kernel XFS reflink flag exchange = disabled
Event History
Frequently Asked Questions
Which filesystem workloads are exposed to this issue?
The issue requires an XFS full-file range exchange where exactly one inode has the reflink flag and the operation uses XFS_EXCHMAPS_INO1_WRITTEN. Hole and unwritten mappings in the first file can be skipped, leaving shared written extents behind after the reflink flag is cleared.
What is the practical impact if the affected exchange occurs?
A later write can take the non-reflink write path for an inode that still owns shared written extents. Those writes can modify blocks that should have been protected by copy-on-write, causing data corruption between reflink-related files.
What behavior does the fix change?
The fix prevents reflink inode flags from being exchanged when XFS_EXCHMAPS_INO1_WRITTEN is requested. The content exchange can still proceed, but both inodes conservatively retain the reflink flag.