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.
A Linux kernel btrfs vulnerability allows incorrect inode size handling during log replay when an inode is logged in full mode followed by logging a new name. This can result in zero-sized inodes retaining non-zero sizes after recovery, potentially causing data inconsistency.
يؤثر هذا الضعف على نواة Linux عند استخدام نظام ملفات btrfs، حيث يحدث خطأ في معالجة حجم inode أثناء إعادة تشغيل السجل. عندما يتم تسجيل inode بالكامل متبوعاً بتسجيل اسم جديد، قد يحتفظ inode بحجم غير صحيح بعد استرجاع البيانات.
A Linux kernel btrfs vulnerability allows incorrect inode size handling during log replay when an inode is logged in full mode followed by logging a new name. This can result in zero-sized inodes retaining non-zero sizes after recovery, potentially causing data inconsistency.
Update the Linux kernel to the latest patched version that resolves the btrfs inode logging issue. Apply security patches from your distribution's kernel repository immediately. Verify filesystem integrity using btrfs check tool after applying patches.
قم بتحديث نواة Linux إلى أحدث إصدار مصحح يحل مشكلة تسجيل inode في btrfs. طبق تصحيحات الأمان من مستودع نواة توزيعتك على الفور. تحقق من سلامة نظام الملفات باستخدام أداة btrfs check بعد تطبيق التصحيحات.