CVE-2022-48971: Bluetooth: Fix not cleanup led when bt_init fails
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix not cleanup led when bt_init fails
bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.
This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:
BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
Call Trace:
<TASK>
led_trigger_register+0x10d/0x4f0
led_trigger_register_simple+0x7d/0x100
bt_init+0x39/0xf7 [bluetooth]
do_one_initcall+0xd0/0x4e0
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue is a cleanup bug in Bluetooth startup. If Bluetooth initialization fails after registering an LED trigger, stale state can later cause a kernel panic. The business impact is most clearly availability, not confirmed data theft or remote compromise.
Executive priority
Treat this as a kernel availability risk with incomplete severity data. Patch through normal kernel maintenance, escalating for fleets with Bluetooth enabled, high uptime requirements, or vendor advisories assigning higher severity.
Technical view
bt_init() registers a Bluetooth LED trigger through bt_leds_init(). On later initialization failure, bt_leds_cleanup() was not called, leaving a freed trigger name such as bluetooth-power reachable by later LED trigger registration and causing a page fault in strcmp().
Likely exposure
Exposure is limited to Linux systems using affected kernel builds with the Bluetooth subsystem present. The source lists affected Linux kernel version entries including 4.9, 4.19.269, 5.4.227, 5.10.159, 5.15.83, 6.0.13, and 6.1.
Exploitation context
The bundle does not report KEV listing, public exploitation, exploit maturity, attack vector, privileges, or CVSS. Evidence supports a kernel panic condition during Bluetooth initialization error handling, but not active exploitation or weaponized abuse.
Researcher notes
The root cause is missing cleanup on a bt_init() failure path after LED trigger registration. The provided evidence does not establish reachability from remote input, reliable triggering conditions, or privilege requirements, so validation should stay source-based and environment-specific.
Mitigation direction
Update to a vendor kernel containing the referenced stable Linux fixes.
Prioritize systems where Bluetooth is enabled or required.
If updates are unavailable, monitor distribution guidance for backported fixes.
Disable unused Bluetooth functionality only if operationally acceptable.
Include this CVE in normal kernel patch verification tracking.
Validation and detection
Inventory Linux kernel versions across endpoints, servers, and appliances.
Check whether Bluetooth support is installed, enabled, or required.
Compare vendor kernel changelogs against the referenced stable commits.
Review crash logs for Bluetooth initialization or LED trigger panics.
Confirm patched systems boot and Bluetooth behavior remains expected.
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-2022-48971 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.