UBUNTU-CVE-2024-58009
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it. Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.
02 / AFFECTED SOFTWARE
Affected packages
62 explicit affected versions
29 explicit affected versions
10 explicit affected versions
11 explicit affected versions
117 explicit affected versions
1 explicit affected versions
96 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
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
16 explicit affected versions
13 explicit affected versions
12 explicit affected versions
38 explicit affected versions
51 explicit affected versions
13 explicit affected versions
108 explicit affected versions
10 explicit affected versions
60 explicit affected versions
10 explicit affected versions
13 explicit affected versions
1 explicit affected versions
10 explicit affected versions
10 explicit affected versions
41 explicit affected versions
96 explicit affected versions
1 explicit affected versions
8 explicit affected versions
13 explicit affected versions
21 explicit affected versions
94 explicit affected versions
6 explicit affected versions
13 explicit affected versions
12 explicit affected versions
107 explicit affected versions
7 explicit affected versions
14 explicit affected versions
12 explicit affected versions
26 explicit affected versions
109 explicit affected versions
39 explicit affected versions
23 explicit affected versions
14 explicit affected versions
5 explicit affected versions
93 explicit affected versions
67 explicit affected versions
3 explicit affected versions
26 explicit affected versions
64 explicit affected versions
12 explicit affected versions
44 explicit affected versions
4 explicit affected versions
4 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
59 explicit affected versions
13 explicit affected versions
7 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
43 explicit affected versions
76 explicit affected versions
74 explicit affected versions
11 explicit affected versions
104 explicit affected versions
106 explicit affected versions
35 explicit affected versions
12 explicit affected versions
13 explicit affected versions
104 explicit affected versions
6 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: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it. Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1
- https://git.kernel.org/stable/c/245d48c1ba3e7a1779c2f4cbc6f581ddc8a78e22
- https://git.kernel.org/stable/c/297ce7f544aa675b0d136d788cad0710cdfb0785
- https://git.kernel.org/stable/c/49c0d55d59662430f1829ae85b969619573d0fa1
- https://git.kernel.org/stable/c/5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1
- https://git.kernel.org/stable/c/691218a50c3139f7f57ffa79fb89d932eda9571e
- https://ubuntu.com/security/CVE-2024-58009
- https://ubuntu.com/security/notices/USN-7516-1
- https://ubuntu.com/security/notices/USN-7516-2
- https://ubuntu.com/security/notices/USN-7516-3
- https://ubuntu.com/security/notices/USN-7516-4
- https://ubuntu.com/security/notices/USN-7516-5
- https://ubuntu.com/security/notices/USN-7516-6
- https://ubuntu.com/security/notices/USN-7516-7
- https://ubuntu.com/security/notices/USN-7516-8
- https://ubuntu.com/security/notices/USN-7516-9
- https://ubuntu.com/security/notices/USN-7517-1
- https://ubuntu.com/security/notices/USN-7517-2
- https://ubuntu.com/security/notices/USN-7517-3
- https://ubuntu.com/security/notices/USN-7518-1
- https://ubuntu.com/security/notices/USN-7539-1
- https://ubuntu.com/security/notices/USN-7640-1
- https://www.cve.org/CVERecord?id=CVE-2024-58009