https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 07:49:10 +0000 https://vulnerability.circl.lu/vuln/cve-2025-68371 <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>scsi: smartpqi: Fix device resources accessed after device removal</p> <p>Correct possible race conditions during device removal.</p> <p>Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.</p> <p>This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.</p> <p>- Check in the device reset handler if the device is still present in the controller&#39;s SCSI device list before running; if not, the reset is skipped.</p> <p>- Cancel any pending TMF work that has not started in sdev_destroy().</p> <p>- Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.</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>scsi: smartpqi: Fix device resources accessed after device removal</p> <p>Correct possible race conditions during device removal.</p> <p>Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.</p> <p>This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.</p> <p>- Check in the device reset handler if the device is still present in the controller&#39;s SCSI device list before running; if not, the reset is skipped.</p> <p>- Cancel any pending TMF work that has not started in sdev_destroy().</p> <p>- Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.</p> https://vulnerability.circl.lu/vuln/cve-2025-68371