CVE-2024-57987: Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()
If insert an USB dongle which chip is not maintained in ic_id_table, it
will hit the NULL point accessed. Add a null point check to avoid the
Kernel Oops.
Security readout for executives and security teams
Plain-English summary
This Linux kernel bug can crash a system when a Realtek Bluetooth USB dongle with an unrecognized chip is inserted. The impact is availability, not data theft or integrity loss. It requires local access and some privilege, so urgency is moderate unless exposed systems allow USB devices in sensitive environments.
Executive priority
Patch through normal kernel maintenance, accelerated for kiosks, shared workstations, labs, and other systems where USB insertion is realistic. This is not currently supported by sources as internet-exploited or data-compromising, but a crash on critical Linux hosts can still disrupt operations.
Technical view
The btrtl_setup_realtek() path in the Linux Bluetooth Realtek driver can dereference NULL when a USB dongle chip is absent from ic_id_table. The CVE maps to CWE-476 and CVSS 5.5: local attack vector, low complexity, low privileges, no user interaction, high availability impact.
Likely exposure
Exposure is limited to affected Linux kernels with Bluetooth Realtek USB dongle handling reachable. Systems where users or local operators can attach USB Bluetooth hardware are most relevant. Remote-only systems without USB or Bluetooth access are less likely exposed. The bundle does not identify specific distributions, appliances, or backported package status.
Exploitation context
The source bundle does not report active exploitation, and KEV status is false. Abuse would depend on local access and a relevant USB dongle scenario causing kernel oops. Treat this primarily as a local denial-of-service risk rather than a confidentiality or integrity incident.
Researcher notes
The evidence supports a NULL pointer dereference in Linux Bluetooth Realtek setup logic, fixed by adding a NULL check. Affected-version data in the bundle is sparse and distribution mapping is absent, so validation should focus on vendor packages, kernel provenance, and whether the stable commits are present.
Mitigation direction
Apply vendor Linux kernel updates containing the referenced stable fixes.
Check distribution advisories for backported fixes before relying on upstream version numbers.
Restrict untrusted USB Bluetooth dongles on sensitive Linux systems.
Disable unused Bluetooth support where operationally acceptable.
Prioritize systems where local users can attach USB devices.
Validation and detection
Inventory Linux kernel versions on systems with Bluetooth or USB dongle access.
Check whether vendor packages include the referenced stable commits.
Confirm Realtek Bluetooth driver exposure on relevant endpoints and servers.
Review crash logs for kernel oops events around USB Bluetooth insertion.
Document exceptions where patching depends on vendor release timing.
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.
cwe · low confidence lookup
CWE-476: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.