https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 14:28:33 +0000 https://vulnerability.circl.lu/vuln/cve-2026-64425 <p><strong>Affected:</strong> Linux, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP</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> <p><strong>Affected:</strong> Linux, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP</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/cve-2026-64425