https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 11:54:16 +0000 https://vulnerability.circl.lu/vuln/cve-2024-56714 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ionic: no double destroy workqueue</p> <p>There are some FW error handling paths that can cause us to try to destroy the workqueue more than once, so let&#39;s be sure we&#39;re checking for that.</p> <p>The case where this popped up was in an AER event where the handlers got called in such a way that ionic_reset_prepare() and thus ionic_dev_teardown() got called twice in a row. The second time through the workqueue was already destroyed, and destroy_workqueue() choked on the bad wq pointer.</p> <p>We didn&#39;t hit this in AER handler testing before because at that time we weren&#39;t using a private workqueue. Later we replaced the use of the system workqueue with our own private workqueue but hadn&#39;t rerun the AER handler testing since then.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ionic: no double destroy workqueue</p> <p>There are some FW error handling paths that can cause us to try to destroy the workqueue more than once, so let&#39;s be sure we&#39;re checking for that.</p> <p>The case where this popped up was in an AER event where the handlers got called in such a way that ionic_reset_prepare() and thus ionic_dev_teardown() got called twice in a row. The second time through the workqueue was already destroyed, and destroy_workqueue() choked on the bad wq pointer.</p> <p>We didn&#39;t hit this in AER handler testing before because at that time we weren&#39;t using a private workqueue. Later we replaced the use of the system workqueue with our own private workqueue but hadn&#39;t rerun the AER handler testing since then.</p> https://vulnerability.circl.lu/vuln/cve-2024-56714