CVE-2026-43118

Root

Cause

When btrfs logs an inode in "exists" mode (e.g., when creating a new hardlink or renaming), it always writes a generation of 0 for the inode item. This is intended to signal log replay to preserve the inode's i_size from the subvolume tree, since extents are not logged in exists mode. However, if the inode was previously logged in full mode with a new i_size of 0 (e.g., by an fsync of a truncated file), the subsequent exists-mode log preserves the generation of 0 but also stores an i_size of 0. During log replay, overwrite_item() sees generation 0 and interprets the zero i_size as a signal to skip the i_size update, leaving the file with its old non-zero size. The fix ensures that the real inode generation is logged when the i_size has already been updated in the current transaction, and that exists-mode logs carry the correct i_size from the commit root when the inode was created in a prior transaction [1].

Exploitation

The vulnerability is exploitable only locally and requires a specific sequence of operations on a btrfs filesystem: creating a file, writing data, syncing, truncating to zero, fsyncing, creating a hardlink, another fsync on the directory, and finally a power failure or crash. After reboot, log replay will incorrectly restore the file to its pre-truncation size (64 KiB in the reported scenario) instead of the expected zero. No special privileges beyond write access to a btrfs mount are needed.

Impact

A successful exploit causes a file to retain stale data after an explicit truncate-to-zero and fsync followed by a crash. This is a data integrity violation: the file's on-disk size does not match the latest committed metadata. An attacker with local access could deliberately craft this sequence to expose previously written data that the owner believed was discarded. The CVSS v3 score is 5.5 (Medium), reflecting the need for local access and specific prior operations.

Mitigation

The Linux kernel has released stable patches that correct the generation and i_size handling during log replay. Users should apply the patch identified by commit fddb157536e67a055597f00a8b4922d5f5ed0826 (or equivalent backports) [2]. The fix appears in both the mainline and stable kernel series; there is no workaround other than avoiding the problematic combination of operations or upgrading to a patched kernel.