https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 21:56:04 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-68396 <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-68396 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069 certfr-2026-avi-1069 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069 https://cve.radiocsirt.org/vuln/euvd-2026-353590 EUVD-2026-353590 https://cve.radiocsirt.org/vuln/euvd-2026-353590 https://cve.radiocsirt.org/vuln/fkie_cve-2026-68396 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: core: wake eh reliably when using scsi_schedule_eh</p> <p>Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler.</p> <p>To fix this, run the scsi_schedule_eh&#39;s scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh&#39;s call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: core: wake eh reliably when using scsi_schedule_eh</p> <p>Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler.</p> <p>To fix this, run the scsi_schedule_eh&#39;s scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh&#39;s call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-68396 https://cve.radiocsirt.org/vuln/ghsa-g3vc-2pr6-9v45 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: core: wake eh reliably when using scsi_schedule_eh</p> <p>Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler.</p> <p>To fix this, run the scsi_schedule_eh&#39;s scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh&#39;s call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: core: wake eh reliably when using scsi_schedule_eh</p> <p>Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler.</p> <p>To fix this, run the scsi_schedule_eh&#39;s scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh&#39;s call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.</p> https://cve.radiocsirt.org/vuln/ghsa-g3vc-2pr6-9v45 https://cve.radiocsirt.org/vuln/msrc_cve-2026-68396 msrc_CVE-2026-68396 https://cve.radiocsirt.org/vuln/msrc_cve-2026-68396 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68396 <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 193 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh&#39;s scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh&#39;s call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.</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 193 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh&#39;s scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh&#39;s call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68396 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730