Skip to content
Fencer Intel
high 7.8

CVE-2026-98974 json

xfs: fix exchange-range-to-eof file size exchange

published 19d ago modified 18d ago also EUVD-2026-108768

cvss
7.8
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 5%
public exploits
0
none known

Summary

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] > > 1. 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 > > 2. 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. > > 3. 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. > > 4. 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 contents > > Block 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---

Patch / fix

  • Linux Linux 7.3
  • linux Debian 13 6.12.115-2
  • linux Debian 14 7.2.11-1

debian advisories DEBIAN-CVE-2026-98974

  • linux Ubuntu 26.10 7.3.0-10.10
  • linux-aws Ubuntu 26.10 7.3.0-1004.4
  • linux-gcp Ubuntu 26.10 7.3.0-1004.4
  • linux-raspi Ubuntu 26.10 7.3.0-1004.4
  • linux-riscv Ubuntu 26.10 7.3.0-10.10.1
  • linux-oracle Ubuntu 26.10 7.3.0-1004.4
  • linux-realtime Ubuntu 26.10 7.3.0-10.10.1

ubuntu advisories UBUNTU-CVE-2026-98974

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel AlmaLinux 10 6.12.0-211.74.1.el10_2
  • rv AlmaLinux 10 6.12.0-211.74.1.el10_2
  • perf AlmaLinux 10 6.12.0-211.74.1.el10_2
  • rtla AlmaLinux 10 6.12.0-211.74.1.el10_2
  • libperf AlmaLinux 10 6.12.0-211.74.1.el10_2
  • kernel-rt AlmaLinux 10 6.12.0-211.74.1.el10_2
  • kernel-64k AlmaLinux 10 6.12.0-211.74.1.el10_2
  • kernel-core AlmaLinux 10 6.12.0-211.74.1.el10_2

almalinux advisories ALSA-2026:95367

  • kernel Rocky Linux 10 6.12.0-211.74.1.el10_2

rocky linux advisories RLSA-2026:95367

Is CVE-2026-98974 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-98974 updated cvss 7.8

kernel: kernel: xfs: Unauthorized data modification via improper file size exchange handling

  • Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    affected: workaround, no fix available
  • Red Hat Enterprise Linux kernel-modules-internal 6.12.0-211.74.1.el10_2 Red Hat Enterprise Linux AppStream (v. 10) rv 6.12.0-211.74.1.el10_2, rv 6.12.0-264.14.1.el10_3, perf 6.12.0-211.74.1.el10_2, perf 6.12.0-264.14.1.el10_3, rtla 6.12.0-211.74.1.el10_2, rtla 6.12.0-264.14.1.el10_3, +20 more Red Hat Enterprise Linux BaseOS (v. 10) kernel 6.12.0-211.74.1.el10_2, kernel 6.12.0-264.14.1.el10_3, kernel-64k 6.12.0-211.74.1.el10_2, kernel-64k 6.12.0-264.14.1.el10_3, kernel-core 6.12.0-211.74.1.el10_2, kernel-core 6.12.0-264.14.1.el10_3, +62 more Red Hat Enterprise Linux CodeReady Linux Builder (v. 10) libperf 6.12.0-211.74.1.el10_2, libperf 6.12.0-264.14.1.el10_3, kernel-debuginfo-common-s390x 6.12.0-211.74.1.el10_2, kernel-debuginfo-common-s390x 6.12.0-264.14.1.el10_3, kernel-debuginfo-common-x86_64 6.12.0-211.74.1.el10_2, kernel-debuginfo-common-x86_64 6.12.0-264.14.1.el10_3, +4 more Red Hat Enterprise Linux Hidden (v. 10) kernel-modules-internal 6.12.0-211.74.1.el10_2, kernel-debuginfo-common-x86_64 6.12.0-211.74.1.el10_2 Red Hat Enterprise Linux Real Time (v. 10) kernel-rt 6.12.0-211.74.1.el10_2, kernel-rt 6.12.0-264.14.1.el10_3, kernel-rt-64k 6.12.0-211.74.1.el10_2, kernel-rt-64k 6.12.0-264.14.1.el10_3, kernel-rt-core 6.12.0-211.74.1.el10_2, kernel-rt-core 6.12.0-264.14.1.el10_3, +34 more
    +1 more products
    Red Hat Enterprise Linux Real Time for NFV (v. 10) kernel-rt 6.12.0-211.74.1.el10_2, kernel-rt 6.12.0-264.14.1.el10_3, kernel-rt-core 6.12.0-211.74.1.el10_2, kernel-rt-core 6.12.0-264.14.1.el10_3, kernel-rt-modules 6.12.0-211.74.1.el10_2, kernel-rt-modules 6.12.0-264.14.1.el10_3, +15 more
    fixed: vendor fix RHSA-2026:95367
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more
    not affected: vulnerable code not present
  • Red Hat Hardened Images erlang27
    not affected: component not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.16% chance of exploitation in the next 30 days, higher than 5% of all scored CVEs (FIRST EPSS, 2026-11-11).

CVSS scores

assigned by version score vector
CNA 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.