https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 17:15:19 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-16228 bdu:2025-16228 https://cve.radiocsirt.org/vuln/bdu:2025-16228 https://cve.radiocsirt.org/vuln/bell-cve-2023-53429 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2023-53429 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-345206 EUVD-2026-345206 https://cve.radiocsirt.org/vuln/euvd-2026-345206 https://cve.radiocsirt.org/vuln/fkie_cve-2023-53429 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: don&#39;t check PageError in __extent_writepage</p> <p>__extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O.</p> <p>Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: don&#39;t check PageError in __extent_writepage</p> <p>__extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O.</p> <p>Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-53429 https://cve.radiocsirt.org/vuln/ghsa-95qf-frmh-4g6j <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: don&#39;t check PageError in __extent_writepage</p> <p>__extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O.</p> <p>Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: don&#39;t check PageError in __extent_writepage</p> <p>__extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O.</p> <p>Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.</p> https://cve.radiocsirt.org/vuln/ghsa-95qf-frmh-4g6j https://cve.radiocsirt.org/vuln/msrc_cve-2023-53429 msrc_CVE-2023-53429 https://cve.radiocsirt.org/vuln/msrc_cve-2023-53429 https://cve.radiocsirt.org/vuln/suse-su-2025:03600-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:03600-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53429 <p><strong>Affected:</strong> 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, Ubuntu:16.04:LTS: linux-hwe-edge and 169 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: don&#39;t check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.</p> <p><strong>Affected:</strong> 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, Ubuntu:16.04:LTS: linux-hwe-edge and 169 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: don&#39;t check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53429 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2092 <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-2092