https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 13:12:39 +0000 https://vulnerability.circl.lu/vuln/bell-cve-2026-64425 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts</p> https://vulnerability.circl.lu/vuln/bell-cve-2026-64425 https://vulnerability.circl.lu/vuln/certfr-2026-avi-0982 certfr-2026-avi-0982 https://vulnerability.circl.lu/vuln/certfr-2026-avi-0982 https://vulnerability.circl.lu/vuln/fkie_cve-2026-64425 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item</p> <p>commit 10dc95939817 (&#34;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#34;) fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.</p> <p>io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun.</p> <p>Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item</p> <p>commit 10dc95939817 (&#34;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#34;) fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.</p> <p>io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun.</p> <p>Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-64425 https://vulnerability.circl.lu/vuln/ghsa-rmw8-w7cg-rwfm <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item</p> <p>commit 10dc95939817 (&#34;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#34;) fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.</p> <p>io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun.</p> <p>Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item</p> <p>commit 10dc95939817 (&#34;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#34;) fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.</p> <p>io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun.</p> <p>Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.</p> https://vulnerability.circl.lu/vuln/ghsa-rmw8-w7cg-rwfm https://vulnerability.circl.lu/vuln/msrc_cve-2026-64425 msrc_CVE-2026-64425 https://vulnerability.circl.lu/vuln/msrc_cve-2026-64425 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11476-1 <p>kernel-devel-7.1.7-1.1 on GA media</p> <p>kernel-devel-7.1.7-1.1 on GA media</p> https://vulnerability.circl.lu/vuln/opensuse-su-2026:11476-1 https://vulnerability.circl.lu/vuln/ssa-019113 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://vulnerability.circl.lu/vuln/ssa-019113 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-64425 <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 189 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (&#34;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#34;) fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.</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 189 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (&#34;io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop&#34;) fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-64425 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2527 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2527