https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 00:20:56 +0000 https://vulnerability.circl.lu/vuln/cve-2026-43118 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix zero size inode with non-zero size after log replay</p> <p>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&#39;t log extents).</p> <p>This works fine except when we have already logged an inode in full mode or it&#39;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&#39;s i_size to 0 (in overwrite_item()).</p> <p>An example scenario:</p> <p>mkdir /mnt/dir xfs_io -f -c &#34;pwrite 0 64K&#34; /mnt/dir/foo</p> <p>sync</p> <p>xfs_io -c &#34;truncate 0&#34; -c &#34;fsync&#34; /mnt/dir/foo</p> <p>ln /mnt/dir/foo /mnt/dir/bar</p> <p>xfs_io -c &#34;fsync&#34; /mnt/dir</p> <p>&lt;power fail&gt;</p> <p>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 generatio…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix zero size inode with non-zero size after log replay</p> <p>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&#39;t log extents).</p> <p>This works fine except when we have already logged an inode in full mode or it&#39;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&#39;s i_size to 0 (in overwrite_item()).</p> <p>An example scenario:</p> <p>mkdir /mnt/dir xfs_io -f -c &#34;pwrite 0 64K&#34; /mnt/dir/foo</p> <p>sync</p> <p>xfs_io -c &#34;truncate 0&#34; -c &#34;fsync&#34; /mnt/dir/foo</p> <p>ln /mnt/dir/foo /mnt/dir/bar</p> <p>xfs_io -c &#34;fsync&#34; /mnt/dir</p> <p>&lt;power fail&gt;</p> <p>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 generatio…</p> https://vulnerability.circl.lu/vuln/cve-2026-43118