UBUNTU-CVE-2024-56714
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.
02 / AFFECTED SOFTWARE
Affected packages
29 explicit affected versions
10 explicit affected versions
11 explicit affected versions
9 explicit affected versions
16 explicit affected versions
13 explicit affected versions
1 explicit affected versions
7 explicit affected versions
26 explicit affected versions
37 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
13 explicit affected versions
78 explicit affected versions
7 explicit affected versions
45 explicit affected versions
37 explicit affected versions
8 explicit affected versions
4 explicit affected versions
8 explicit affected versions
19 explicit affected versions
23 explicit affected versions
7 explicit affected versions
10 explicit affected versions
33 explicit affected versions
2 explicit affected versions
12 explicit affected versions
38 explicit affected versions
51 explicit affected versions
13 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
1 explicit affected versions
10 explicit affected versions
10 explicit affected versions
1 explicit affected versions
8 explicit affected versions
13 explicit affected versions
21 explicit affected versions
6 explicit affected versions
26 explicit affected versions
13 explicit affected versions
12 explicit affected versions
7 explicit affected versions
14 explicit affected versions
12 explicit affected versions
26 explicit affected versions
23 explicit affected versions
14 explicit affected versions
5 explicit affected versions
3 explicit affected versions
12 explicit affected versions
44 explicit affected versions
4 explicit affected versions
4 explicit affected versions
13 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
13 explicit affected versions
7 explicit affected versions
10 explicit affected versions
14 explicit affected versions
18 explicit affected versions
3 explicit affected versions
16 explicit affected versions
6 explicit affected versions
43 explicit affected versions
11 explicit affected versions
35 explicit affected versions
12 explicit affected versions
13 explicit affected versions
12 explicit affected versions
50 explicit affected versions
11 explicit affected versions
12 explicit affected versions
27 explicit affected versions
12 explicit affected versions
7 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/746e6ae2e202b062b9deee7bd86d94937997ecd7
- https://git.kernel.org/stable/c/13355dd37e22edbcb99c599f783233188740a650
- https://git.kernel.org/stable/c/746e6ae2e202b062b9deee7bd86d94937997ecd7
- https://ubuntu.com/security/CVE-2024-56714
- https://ubuntu.com/security/notices/USN-7379-1
- https://ubuntu.com/security/notices/USN-7379-2
- https://ubuntu.com/security/notices/USN-7380-1
- https://ubuntu.com/security/notices/USN-7381-1
- https://ubuntu.com/security/notices/USN-7382-1
- https://www.cve.org/CVERecord?id=CVE-2024-56714