CVE-2024-50148: Bluetooth: bnep: fix wild-memory-access in proto_unregister
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: fix wild-memory-access in proto_unregister
There's issue as follows:
KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W
RIP: 0010:proto_unregister+0xee/0x400
Call Trace:
<TASK>
__do_sys_delete_module+0x318/0x580
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit().
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel Bluetooth BNEP cleanup bug that can crash affected systems when the module cleanup path mishandles already-cleaned socket resources. It is rated medium because exploitation requires local privileges, but the availability impact is high for systems that load the affected Bluetooth networking code.
Executive priority
Treat as a routine but real kernel availability risk. Patch through normal Linux kernel maintenance, with higher priority for systems where Bluetooth networking is enabled or where unplanned reboot risk is business-critical.
Technical view
The bug is in Linux Bluetooth BNEP error handling. bnep_init ignored bnep_sock_init failure, while cleanup could later call bnep_sock_cleanup again, leading to wild memory access in proto_unregister during module removal. The CVSS vector is local, low complexity, low privileges, no user interaction, availability-only impact.
Likely exposure
Exposure is most relevant on Linux systems using or loading the Bluetooth BNEP module. Servers without Bluetooth support or without this module loaded are less likely exposed, but distribution backports must be checked.
Exploitation context
The source bundle does not show active exploitation, and KEV is false. The observed failure path involves local module removal and kernel cleanup behavior, so this is primarily a local denial-of-service concern.
Researcher notes
Evidence supports a local availability impact in Linux Bluetooth BNEP cleanup logic. No confidentiality or integrity impact is indicated by the CVSS vector. Confirm affected status through vendor kernels because distributions often backport fixes without changing upstream version numbers.
Mitigation direction
Apply vendor kernel updates that include the referenced stable fixes.
Check Debian LTS advisories if running affected Debian kernels.
Review Siemens guidance for affected industrial products.
Follow your Linux distribution’s kernel security advisory and reboot requirements.
Prioritize hosts where Bluetooth or BNEP is enabled.
Validation and detection
Inventory Linux kernel versions and distribution patch levels.
Check whether Bluetooth BNEP support is built or loaded.
Confirm installed kernels include vendor fixes for CVE-2024-50148.
Review change records for kernel versions 4.19.323, 5.4.285, 5.10.229, 5.15.170, 6.1.115, 6.6.59, 6.11.6, or later vendor equivalents.
Document any appliances covered by the Siemens advisory.
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-50148 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.