PT-2026-37428 · Linux · Linux
Published
2026-05-06
·
Updated
2026-05-06
·
CVE-2026-43118
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux