PT-2026-121951
CVE-2026-98974
·
Published
2026-10-23
·
Updated
2026-10-23
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix exchange-range-to-eof file size exchange
Norbert Szetei posted a patch containing an incomplete description of a
bug in XFS IOC EXCHANGE RANGE's TO EOF flag. The bug tricks
exchange-range into modifying a file so that it has shared blocks
starting beyond EOF, which is never allowed because files never have
written data beyond EOF, and you can only share written data blocks.
This is key to all the incorrect behavior that follows.
Eventually I got from Norbert a description of what's going wrong:
Fair. Here it is with physical block numbers, 4k blocks. peer is the file that gets rewritten and file1 is the one that ends up with the flag cleared.Start, nothing shared:peer size 4096 -> [100] file1 size 12288 -> [200] [201] [202] donor1 size 4096 -> [300] donor2 size 4096 -> [400]
- FICLONERANGE peer's block into file1's middle slot:
peer size 4096 -> [100] file1 size 12288 -> [200] [100] [202] reflink flag set ^^^^^ both files own block 100
- XFS IOC EXCHANGE RANGE file1 against donor1, file1 offset 0, file2 offset 8192, length 0, TO EOF. One block is exchanged, and the sizes are exchanged with it:
file1 size 4096 -> [200] [100] [300] reflink flag set ^^^^^^^^^^^ still owned, now past the size donor1 size 12288 -> [202]file1 says it is one block long while it still owns three. Nothing was unmapped. file2 offset is block 2, so this exchange cannot clear a flag.
- XFS IOC EXCHANGE RANGE file1 against donor2, both offsets 0, length 4096. By i disk size this is two one-block files exchanging everything, so xmi can exchange reflink flags() agrees and the flag is cleared:
file1 size 4096 -> [400] [100] [300] reflink flag CLEARED donor2 size 4096 -> [200]Block 100 is still shared with peer.
- pwrite(file1, 4096, 4096), which is file1's second slot, block 100. xfs is cow inode(file1) is false, so no CoW:
peer size 4096 -> [100] same block, new contentsBlock 100 is the only one that matters here. PoC below, it reads a file called peer in the current directory. The filesystem needs reflink and exchange-range, which mkfs.xfs 7.x turns on by default.
So yes, TO EOF is screwing up the file size even if it's actually
exchanging the data block correctly. The following is the intended
behavior of XFS EXCHANGE RANGE TO EOF, as described by its manpage:
"Ignore the length parameter. All bytes in file1 fd from file1 offset
to EOF are moved to file2 fd, and file2's size is set to
(file2 offset+(file1 length-file1 offset)). Meanwhile, all bytes in
file2 from file2 offset to EOF are moved to file1 and file1's size is
set to (file1 offset+(file2 length-file2 offset))."
In other words, if we only exchange a portion of the file data, then we
should only exchange the portion of the file size that relates to the
exchanged data. Unfortunately, the code swaps the ondisk file size and
the incore file sizes, which is incorrect if the caller passes in a
nonzero offset.
Having confused the file sizes, the PoC uses a second exchange-range
call on what looks like a non-reflinked single-block file. Because the
file size is set incorrectly, exchange-range thinks it's exchanging the
full contents of two files and clears the reflink flag on the broken
file. That enables an extending write of the broken file to rewrite the
shared block that's just past EOF. This has become known colloquially
as refluxfs.
Once the file sizes are set correctly, the second exchange-range no
longer thinks that it's doing a full-contents swap, so it won't clear
the reflink flag on either of its file arguments.
Norbert followed up to an earlier version of this patch with a second
complaint about us not handling the i disk size state correctly:
The offsets are bounded against the incore i size but subtracted from
---truncated---
Found an issue in the description? Have something to add? Feel free to write us 👾