CVE-2026-80530 in Linux
Summary
by MITRE • 08/26/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The XFS filesystem implementation within the Linux kernel contains a critical logic flaw regarding the handling of reference count flags during range exchange operations, specifically when the INO1_WRITTEN flag is active. This vulnerability arises from an incorrect assumption made by the xmi_can_exchange_reflink_flags function, which governs how reflink inode attributes are transferred between two files during an extent swap operation. Under normal circumstances where both file ranges consist entirely of shared or unwritten extents that will be fully swapped, moving the reflink flag from one inode to another is a safe optimization that maintains data integrity by ensuring only one inode retains responsibility for copy-on-write protections. However, this logic fails when the XFS_EXCHMAPS_INO1_WRITTEN flag is set in the exchange map structure. This flag indicates that file one contains written extents that are not being fully exchanged or modified in a way that preserves their shared status relative to file two.
The core technical failure occurs because the xfs_exchmaps_can_skip_mapping function allows for the skipping of hole and unwritten mappings from file one during the exchange process. Consequently, an exchange operation can complete successfully without moving every mapping that was considered when the initial reflink flag swap decision was made. This discrepancy creates a state where the post-operation cleanup routine incorrectly clears the reflink inode flag from an inode that still owns shared written extents. By removing this protective attribute prematurely, the filesystem loses track of which inodes are responsible for managing copy-on-write semantics for those specific blocks. The system erroneously believes that no other file references these data blocks because it has stripped the metadata indicating their shared nature.
The operational impact of this vulnerability is severe and manifests as silent data corruption between files that share extents through reflink mechanisms. When a subsequent write operation targets one of these affected inodes, the kernel follows the standard non-reflink write path rather than the copy-on-write path. This bypasses the necessary mechanism for duplicating shared blocks before modification, leading to direct overwrites of data that is still logically referenced by another inode. As a result, changes intended for only one file inadvertently corrupt the other, violating the fundamental isolation guarantees expected from reflink functionality and potentially causing application-level errors or loss of critical user data depending on which files are involved in the corrupted exchange.
To mitigate this vulnerability, the kernel developers have implemented a fix that disables the automatic exchange of reflink flags whenever XFS_EXCHMAPS_INO1_WRITTEN is requested during an extent swap operation. This conservative approach ensures that both inodes retain their respective reflink flags after the exchange completes, even if one side contains written extents that were not fully swapped. While this may result in a temporary state where more than one inode holds the flag for certain blocks, it preserves data integrity by maintaining the correct copy-on-write protections until such time as the inode no longer possesses any shared extents. At that point, the regular reflink flag cleanup path can safely drop the redundant flags without risking corruption. This fix aligns with CWE-682 regarding Incorrect Calculation and addresses a logic error in state management within file system metadata handling, ensuring that reference counting mechanisms remain consistent with actual block sharing status to prevent unauthorized data modification via ATT&CK technique T1490 or similar persistence vectors involving storage manipulation.