https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 07:04:43 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-43118 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-43118 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0927 certfr-2026-avi-0927 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0927 https://cve.radiocsirt.org/vuln/euvd-2026-315756 EUVD-2026-315756 https://cve.radiocsirt.org/vuln/euvd-2026-315756 https://cve.radiocsirt.org/vuln/fkie_cve-2026-43118 <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>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://cve.radiocsirt.org/vuln/fkie_cve-2026-43118 https://cve.radiocsirt.org/vuln/ghsa-hwg8-9qf4-vr6j <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>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://cve.radiocsirt.org/vuln/ghsa-hwg8-9qf4-vr6j https://cve.radiocsirt.org/vuln/msrc_cve-2026-43118 msrc_CVE-2026-43118 https://cve.radiocsirt.org/vuln/msrc_cve-2026-43118 https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-1 https://cve.radiocsirt.org/vuln/suse-su-2026:23066-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:23066-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43118 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 233 more</p> <p>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&#39;t log extents). 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()). An example scenario: mkdir /mnt/dir xfs_io -f -c &#34;pwrite 0 64K&#34; /mnt/dir/foo sync xfs_io -c &#34;truncate 0&#34; -c &#34;fsync&#34; /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c &#34;fsync&#34; /mnt/dir &lt;power fail&gt; 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…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 233 more</p> <p>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&#39;t log extents). 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()). An example scenario: mkdir /mnt/dir xfs_io -f -c &#34;pwrite 0 64K&#34; /mnt/dir/foo sync xfs_io -c &#34;truncate 0&#34; -c &#34;fsync&#34; /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c &#34;fsync&#34; /mnt/dir &lt;power fail&gt; 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…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43118 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1385 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen oder potentiell beliebigen Programmcode auszuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen oder potentiell beliebigen Programmcode auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1385