CVE-2024-41062: bluetooth/l2cap: sync sock recv cb and release
In the Linux kernel, the following vulnerability has been resolved:
bluetooth/l2cap: sync sock recv cb and release
The problem occurs between the system call to close the sock and hci_rx_work,
where the former releases the sock and the latter accesses it without lock protection.
CPU0 CPU1
---- ----
sock_close hci_rx_work
l2cap_sock_release hci_acldata_packet
l2cap_sock_kill l2cap_recv_frame
sk_free l2cap_conless_channel
l2cap_sock_recv_cb
If hci_rx_work processes the data that needs to be received before the sock is
closed, then everything is normal; Otherwise, the work thread may access the
released sock when receiving data.
Add a chan mutex in the rx callback of the sock to achieve synchronization between
the sock release and recv cb.
Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.
Security readout for executives and security teams
Plain-English summary
A Linux Bluetooth race condition can let incoming L2CAP processing use a socket after another processor has closed and freed it. This may corrupt kernel memory and compromise confidentiality, integrity, or availability. Exploitation requires adjacent-network access according to the supplied CVSS vector; it is not presented as internet-reachable.
Executive priority
Treat this as a high-priority kernel update for Bluetooth-enabled Linux systems exposed to nearby untrusted devices. Prioritize public, shared, or physically accessible environments. Systems without usable Bluetooth are lower priority, but version and configuration should still be verified because the supplied evidence does not define every distribution's affected package range.
Technical view
The flaw is a use-after-free race between l2cap_sock_release and l2cap_sock_recv_cb during hci_rx_work. Socket release can free the object before receive processing accesses it. The upstream correction synchronizes receive and release using the channel mutex and clears channel data after socket death to prevent reuse of an invalid pointer.
Likely exposure
Exposure is most likely on affected Linux kernels where Bluetooth and the relevant L2CAP path are available to nearby traffic. The supplied version data is ambiguous and may not reflect distribution backports. Determine exposure from the running vendor kernel package and its advisory or fix status, not the upstream version number alone.
Exploitation context
The supplied CVSS 3.1 score is 8.8 with adjacent-network access, low complexity, no privileges, and no user interaction. The race may affect confidentiality, integrity, and availability. The bundle marks the CVE as absent from KEV and provides no evidence of active exploitation or a public exploit.
Researcher notes
The central issue is synchronization of socket lifetime with the receive callback, not a protocol parsing defect. The fix adds channel locking around receive processing and nulls the channel's socket pointer after death. No CWE, exploit method, affected hardware list, or dependable distribution-wide version boundary is supplied; analyze vendor backports and the referenced stable commits.
Mitigation direction
Install a vendor-supported kernel update containing the applicable stable fix.
Consult the Linux distribution advisory because vendors may backport fixes without changing upstream version identifiers.
Where operationally acceptable, disable unused Bluetooth functionality until patched.
Prioritize systems whose Bluetooth interfaces are enabled or accessible in untrusted physical environments.
Validation and detection
Record each system's running kernel and distribution package version.
Confirm the vendor package explicitly addresses CVE-2024-41062 or includes the applicable stable fix.
Verify Bluetooth exposure and whether the relevant L2CAP functionality is enabled.
After updating, confirm the patched kernel is running following any required reboot.
Review kernel logs for Bluetooth-related crashes or memory-safety symptoms without treating their absence as proof of safety.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-41062 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.