https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 19:29:59 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-05857 bdu:2026-05857 https://cve.radiocsirt.org/vuln/bdu:2026-05857 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895 certfr-2025-avi-0895 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895 https://cve.radiocsirt.org/vuln/euvd-2026-311218 EUVD-2026-311218 https://cve.radiocsirt.org/vuln/euvd-2026-311218 https://cve.radiocsirt.org/vuln/fkie_cve-2022-50428 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ext4: fix off-by-one errors in fast-commit block filling</p> <p>Due to several different off-by-one errors, or perhaps due to a late change in design that wasn&#39;t fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries:</p> <p>- tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn&#39;t seem to happen currently.)</p> <p>- tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks.</p> <p>Also, strangely these constraints don&#39;t apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...).</p> <p>Given that this all seems to be a bug, let&#39;s fix it by just filling blocks with tlv entries in the natural way.</p> <p>Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ext4: fix off-by-one errors in fast-commit block filling</p> <p>Due to several different off-by-one errors, or perhaps due to a late change in design that wasn&#39;t fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries:</p> <p>- tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn&#39;t seem to happen currently.)</p> <p>- tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks.</p> <p>Also, strangely these constraints don&#39;t apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...).</p> <p>Given that this all seems to be a bug, let&#39;s fix it by just filling blocks with tlv entries in the natural way.</p> <p>Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-50428 https://cve.radiocsirt.org/vuln/ghsa-362x-q9rc-h58c <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ext4: fix off-by-one errors in fast-commit block filling</p> <p>Due to several different off-by-one errors, or perhaps due to a late change in design that wasn&#39;t fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries:</p> <p>- tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn&#39;t seem to happen currently.)</p> <p>- tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks.</p> <p>Also, strangely these constraints don&#39;t apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...).</p> <p>Given that this all seems to be a bug, let&#39;s fix it by just filling blocks with tlv entries in the natural way.</p> <p>Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ext4: fix off-by-one errors in fast-commit block filling</p> <p>Due to several different off-by-one errors, or perhaps due to a late change in design that wasn&#39;t fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries:</p> <p>- tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn&#39;t seem to happen currently.)</p> <p>- tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks.</p> <p>Also, strangely these constraints don&#39;t apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...).</p> <p>Given that this all seems to be a bug, let&#39;s fix it by just filling blocks with tlv entries in the natural way.</p> <p>Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.</p> https://cve.radiocsirt.org/vuln/ghsa-362x-q9rc-h58c https://cve.radiocsirt.org/vuln/suse-su-2025:03615-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:03615-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50428 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 104 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one errors in fast-commit block filling Due to several different off-by-one errors, or perhaps due to a late change in design that wasn&#39;t fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries: - tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn&#39;t seem to happen currently.) - tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks. Also, strangely these constraints don&#39;t apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...). Given that this all seems to be a bug, let&#39;s fix it by just filling blocks with tlv entries in the natural way. Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 104 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one errors in fast-commit block filling Due to several different off-by-one errors, or perhaps due to a late change in design that wasn&#39;t fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries: - tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn&#39;t seem to happen currently.) - tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks. Also, strangely these constraints don&#39;t apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...). Given that this all seems to be a bug, let&#39;s fix it by just filling blocks with tlv entries in the natural way. Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50428 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2187 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2187