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.
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.
Metrics
Affected Vendors & Products
Advisories
Source | ID | Title |
---|---|---|
![]() |
DLA-4102-1 | linux-6.1 security update |
![]() |
EUVD-2025-5203 | 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. |
![]() |
USN-7516-1 | Linux kernel vulnerabilities |
![]() |
USN-7516-2 | Linux kernel (GCP FIPS) vulnerabilities |
![]() |
USN-7516-3 | Linux kernel vulnerabilities |
![]() |
USN-7516-4 | Linux kernel (Oracle) vulnerabilities |
![]() |
USN-7516-5 | Linux kernel (HWE) vulnerabilities |
![]() |
USN-7516-6 | Linux kernel (IBM) vulnerabilities |
![]() |
USN-7516-7 | Linux kernel (AWS) vulnerabilities |
![]() |
USN-7516-8 | Linux kernel (FIPS) vulnerabilities |
![]() |
USN-7516-9 | Linux kernel (AWS) vulnerabilities |
![]() |
USN-7517-1 | Linux kernel (Xilinx ZynqMP) vulnerabilities |
![]() |
USN-7517-2 | Linux kernel (IBM) vulnerabilities |
![]() |
USN-7517-3 | Linux kernel (BlueField) vulnerabilities |
![]() |
USN-7518-1 | Linux kernel (Azure FIPS) vulnerabilities |
![]() |
USN-7539-1 | Linux kernel (Raspberry Pi) vulnerabilities |
![]() |
USN-7640-1 | Linux kernel (IoT) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Wed, 22 Oct 2025 19:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Weaknesses | CWE-476 | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
Vendors & Products |
Linux
Linux linux Kernel |
Fri, 16 May 2025 03:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Redhat
Redhat enterprise Linux |
|
CPEs | cpe:/a:redhat:enterprise_linux:9 cpe:/o:redhat:enterprise_linux:9 |
|
Vendors & Products |
Redhat
Redhat enterprise Linux |
Thu, 13 Mar 2025 12:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Fri, 28 Feb 2025 02:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Thu, 27 Feb 2025 02:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | 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. | |
Title | Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc | |
References |
|
|

Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-04T10:08:19.816Z
Reserved: 2025-02-27T02:10:48.227Z
Link: CVE-2024-58009

No data.

Status : Analyzed
Published: 2025-02-27T03:15:11.880
Modified: 2025-10-22T19:39:52.967
Link: CVE-2024-58009


No data.