ionic: no double destroy workqueue
There are some FW error handling paths that can cause us to
try to destroy the workqueue more than once, so let's be sure
we're checking for that.
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.
We didn't hit this in AER handler testing before because at
that time we weren't using a private workqueue. Later we
replaced the use of the system workqueue with our own private
workqueue but hadn't rerun the AER handler testing since then.
Metrics
Affected Vendors & Products
Source | ID | Title |
---|---|---|
![]() |
EUVD-2024-53362 | In the Linux kernel, the following vulnerability has been resolved: ionic: no double destroy workqueue There are some FW error handling paths that can cause us to try to destroy the workqueue more than once, so let's be sure we're checking for that. 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. We didn't hit this in AER handler testing before because at that time we weren't using a private workqueue. Later we replaced the use of the system workqueue with our own private workqueue but hadn't rerun the AER handler testing since then. |
![]() |
USN-7379-1 | Linux kernel vulnerabilities |
![]() |
USN-7379-2 | Linux kernel (Raspberry Pi) vulnerabilities |
![]() |
USN-7380-1 | Linux kernel (Low Latency) vulnerabilities |
![]() |
USN-7381-1 | Linux kernel (Low Latency) vulnerabilities |
![]() |
USN-7382-1 | Linux kernel (OEM) vulnerabilities |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Wed, 15 Oct 2025 17:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | NVD-CWE-noinfo | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:* |
|
Metrics |
cvssV3_1
|
cvssV3_1
|
Tue, 04 Mar 2025 15:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | CWE-99 | |
Metrics |
cvssV3_1
|
cvssV3_1
|
Mon, 30 Dec 2024 01:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Sun, 29 Dec 2024 09:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | In the Linux kernel, the following vulnerability has been resolved: ionic: no double destroy workqueue There are some FW error handling paths that can cause us to try to destroy the workqueue more than once, so let's be sure we're checking for that. 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. We didn't hit this in AER handler testing before because at that time we weren't using a private workqueue. Later we replaced the use of the system workqueue with our own private workqueue but hadn't rerun the AER handler testing since then. | |
Title | ionic: no double destroy workqueue | |
References |
|

Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-04T10:03:09.612Z
Reserved: 2024-12-27T15:00:39.857Z
Link: CVE-2024-56714

No data.

Status : Analyzed
Published: 2024-12-29T09:15:06.510
Modified: 2025-10-15T17:42:17.180
Link: CVE-2024-56714


Updated: 2025-07-13T11:14:03Z