Description
In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix zero size inode with non-zero size after log replay

When logging that an inode exists, as part of logging a new name or
logging new dir entries for a directory, we always set the generation of
the logged inode item to 0. This is to signal during log replay (in
overwrite_item()), that we should not set the i_size since we only logged
that an inode exists, so the i_size of the inode in the subvolume tree
must be preserved (as when we log new names or that an inode exists, we
don't log extents).

This works fine except when we have already logged an inode in full mode
or it's the first time we are logging an inode created in a past
transaction, that inode has a new i_size of 0 and then we log a new name
for the inode (due to a new hardlink or a rename), in which case we log
an i_size of 0 for the inode and a generation of 0, which causes the log
replay code to not update the inode's i_size to 0 (in overwrite_item()).

An example scenario:

mkdir /mnt/dir
xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo

sync

xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo

ln /mnt/dir/foo /mnt/dir/bar

xfs_io -c "fsync" /mnt/dir

<power fail>

After log replay the file remains with a size of 64K. This is because when
we first log the inode, when we fsync file foo, we log its current i_size
of 0, and then when we create a hard link we log again the inode in exists
mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we
add to the log tree, so during log replay overwrite_item() sees that the
generation is 0 and i_size is 0 so we skip updating the inode's i_size
from 64K to 0.

Fix this by making sure at fill_inode_item() we always log the real
generation of the inode if it was logged in the current transaction with
the i_size we logged before. Also if an inode created in a previous
transaction is logged in exists mode only, make sure we log the i_size
stored in the inode item located from the commit root, so that if we log
multiple times that the inode exists we get the correct i_size.

A test case for fstests will follow soon.
Published: 2026-05-06
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The bug causes btrfs to preserve an inode’s size when replaying a transaction log, even when the inode’s actual size has been changed to zero earlier in the same or a previous transaction. As a result, a file that was truncated but then hard‑linked or renamed during a crash can retain a stale large size after the system recovers, corrupting data and potentially overwriting unrelated sectors.

Affected Systems

All Linux kernels that implement the btrfs filesystem and have not incorporated the patch corresponding to commits 03e966b, 5254d418, and fddb157. The issue applies to any btrfs instance regardless of the node or deployment environment.

Risk and Exploitability

Although this flaw is not remotely exploitable, it can be triggered by a power failure, unclean shutdown, or crash that occurs after an inode is logged with an incorrect generation and size. The CVSS score of 5.5 indicates moderate severity, and the EPSS score of <1% suggests a low probability of exploitation. The lack of a KEV listing further indicates no widespread exploitation to date. Nevertheless, the impact on data consistency is significant, and administrators should treat the vulnerability as a moderate‑risk issue when running btrfs on critical storage volumes.

Generated by OpenCVE AI on May 8, 2026 at 19:40 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a release that includes the btrfs inode size fix based on the cited commits
  • Ensure that critical systems perform graceful shutdowns and minimize abrupt power loss
  • Run integrity checks and maintain off‑site backups for data protected by btrfs to mitigate potential loss

Generated by OpenCVE AI on May 8, 2026 at 19:40 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 08 May 2026 17:45:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
CPEs cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Thu, 07 May 2026 02:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Thu, 07 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-448
References
Metrics threat_severity

None

 cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate

Wed, 06 May 2026 12:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Wed, 06 May 2026 09:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: btrfs: fix zero size inode with non-zero size after log replay When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents). This works fine except when we have already logged an inode in full mode or it's the first time we are logging an inode created in a past transaction, that inode has a new i_size of 0 and then we log a new name for the inode (due to a new hardlink or a rename), in which case we log an i_size of 0 for the inode and a generation of 0, which causes the log replay code to not update the inode's i_size to 0 (in overwrite_item()). An example scenario: mkdir /mnt/dir xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo sync xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c "fsync" /mnt/dir <power fail> After log replay the file remains with a size of 64K. This is because when we first log the inode, when we fsync file foo, we log its current i_size of 0, and then when we create a hard link we log again the inode in exists mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we add to the log tree, so during log replay overwrite_item() sees that the generation is 0 and i_size is 0 so we skip updating the inode's i_size from 64K to 0. Fix this by making sure at fill_inode_item() we always log the real generation of the inode if it was logged in the current transaction with the i_size we logged before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log the i_size stored in the inode item located from the commit root, so that if we log multiple times that the inode exists we get the correct i_size. A test case for fstests will follow soon.
Title btrfs: fix zero size inode with non-zero size after log replay
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T22:18:06.327Z

Reserved: 2026-05-01T14:12:55.987Z

Link: CVE-2026-43118

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-05-06T10:16:25.633

Modified: 2026-05-08T17:30:34.710

Link: CVE-2026-43118

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-06T00:00:00Z

Links: CVE-2026-43118 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-08T19:45:15Z

Weaknesses