Security readout for executives and security teams
Plain-English summary
A flaw in the Linux btnxpuart Bluetooth driver can crash the kernel when the driver is repeatedly removed and reloaded. The failure occurs because queued power-saving work may execute after the module has been removed. This can disrupt affected systems, but the supplied sources do not establish remote exploitation or attacks in the wild.
Executive priority
Prioritize affected appliances and embedded Linux systems where Bluetooth availability or kernel stability is operationally important. Remediate through normal high-severity kernel maintenance. Escalate urgency where untrusted local users can manage relevant devices or modules, but do not treat this as confirmed active or remote exploitation.
Technical view
btnxpuart_close() calls ps_wakeup(), scheduling work that may run after module removal and reference unloaded code. The kernel fix adds ps_cleanup() to deassert UART break, cancel scheduled power-saving work, and destroy its mutex during device closure. The supplied CVSS is 7.8 with local, low-privilege access required.
Likely exposure
Exposure is limited to Linux systems using the btnxpuart Bluetooth UART driver, particularly where it can be unloaded or devices are removed. The bundle's affected-version entries conflict with its statement that the issue is present since v6.9.11, so kernel and distribution advisories should determine exact exposure.
Exploitation context
CISA KEV status is false, and the supplied sources provide no evidence of active exploitation or a public weaponized exploit. The documented failure arose during repeated driver load and unload testing. CVSS characterizes access as local with low privileges and no user interaction; remote reachability is not established.
Researcher notes
The evidence supports an asynchronous-work cleanup defect during module teardown. The crash trace comes from an FSL i.MX8MM EVK running a customized 6.1.36-based kernel, while the bundle separately says present since v6.9.11 and lists inconsistent versions. Validate ancestry and backports using vendor kernel sources before declaring a release vulnerable.
Mitigation direction
Install a vendor-supported kernel containing the referenced btnxpuart cleanup fix.
Confirm the distribution's advisory maps the fix to its backported kernel version.
Until patched, avoid unnecessary btnxpuart unloading or repeated Bluetooth device removal.
Restrict local administrative capabilities used to manage kernel modules.
Validation and detection
Determine whether the btnxpuart module is present and used on each system.
Compare the running kernel against vendor advisories and referenced stable commits.
Review kernel logs for btnxpuart-related paging faults, Oops events, or crashes.
Test remediation in staging without reproducing repeated unsafe unload cycles on production systems.
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-46680 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.