Bug 2524492 (CVE-2026-80530) - CVE-2026-80530 kernel: xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN
Summary: CVE-2026-80530 kernel: xfs: fix exchange-range reflink flag clearing issue wi...
Keywords:
Status: NEW
Alias: CVE-2026-80530
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-26 15:00 UTC by OSIDB Bzimport
Modified: 2026-09-04 00:05 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-08-26 15:00:57 UTC
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.

Comment 1 Mauro Matteo Cascella 2026-08-26 17:22:58 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026082603-CVE-2026-80530-4a96@gregkh/T

Comment 7 Akiyoshi Kurita 2026-09-04 00:05:21 UTC
Additional information for CVE-2026-80530:

A public oss-security disclosure describes this issue as a deterministic local privilege escalation to root and states that RHEL 10 / Rocky Linux 10 were tested and confirmed vulnerable when the XFS exchange feature is enabled.

oss-security disclosure:
https://www.openwall.com/lists/oss-security/2026/09/03/1

PoC reference:
https://github.com/corvusaisec/security-research/tree/main/pocs/linux/cve-2026-80530

The referenced PoC URL currently returns HTTP 404 (Not Found).

Upstream fix:
https://git.kernel.org/linus/b2d5a81dae385333f9734910277fbf94c78bd17f

Stable kernel backport reference:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2efbd8890b53f4756fdc7b0ef346fa514ffb7d66

Possible mitigation:

If XFS is not used on the system, preventing the XFS module from loading may reduce exposure:

    echo "install xfs /bin/true" > /etc/modprobe.d/disable-xfs.conf

This mitigation should only be used on systems that do not require XFS. If the xfs module is already loaded, adding this configuration alone does not unload it, so a reboot may be required.

The mitigation must not be used if the root filesystem or any required filesystem uses XFS.

The disclosure also notes that exploitation requires XFS with reflink enabled and the exchange_range feature enabled; exchange_range is experimental and disabled by default.


Note You need to log in before you can comment on or make changes to this bug.