CVE-2026-43069

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Bluetooth HCI LL driver. When the driver requests firmware and the firmware file is present but invalid, such as empty or containing no usable data, the error path returns without calling release_firmware(). Repeatedly triggering this path can leak kernel-managed firmware resources and memory, potentially degrading system stability or causing availability loss. The issue does not provide confidentiality or integrity impact and is not remotely exploitable based on the published vector.

Why it matters to the business

Affected Linux systems with the vulnerable Bluetooth HCI LL driver path exposed may be susceptible to local availability disruption. In practical terms, an attacker with local access could attempt to exhaust resources and destabilize systems that rely on the affected Bluetooth driver. The risk is currently lower because EPSS is very low, there is no known public exploit maturity, and it is not listed in CISA KEV; however, kernel availability bugs should still be remediated through normal kernel update cycles, especially on fleets where local users, containers, shared workloads, or physical access are common.

How an attack unfolds

An attacker first obtains local access with enough privileges or system interaction capability to influence the affected Bluetooth firmware-loading path. They cause the hci_ll driver to request a firmware file that exists but is invalid, for example zero-length or otherwise lacking expected content. Because the vulnerable error path fails to release the firmware object after request_firmware() succeeds, each trigger leaks resources. By repeatedly inducing this failure condition, the attacker can consume kernel memory or firmware-related resources until the system becomes unstable, Bluetooth functionality fails, or the host experiences broader denial-of-service symptoms such as hangs, crashes, or forced reboots.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Bluetooth hci_ll firmware-release error path. Because no exact fixed package versions were provided, use the fixed kernel version supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Where immediate patching is not possible, reduce exposure by disabling unused Bluetooth functionality, preventing untrusted local users from loading or manipulating Bluetooth-related drivers and firmware files, restricting write access to firmware directories such as /lib/firmware, and enforcing standard least-privilege controls. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel version is older than the vendor-provided fixed build and whether the affected hci_ll Bluetooth driver is present, built in, or loadable. Validate remediation by confirming the host has rebooted into the fixed kernel, reviewing the vendor changelog for the hci_ll release_firmware() fix, and verifying that Bluetooth firmware-loading error tests no longer result in increasing unreclaimed memory or repeated driver failures. On Linux systems, compare `uname -r` to the fixed vendor kernel, inspect installed kernel package versions through the system package manager, and check loaded Bluetooth modules with tools such as `lsmod`, `modinfo`, or equivalent distribution tooling.

Typical attack path

1. Gain local access to an affected Linux system where the Bluetooth HCI LL driver is present or loadable.
2. Identify or create conditions that cause the hci_ll driver to invoke firmware loading.
3. Ensure the requested firmware content is invalid, empty, or otherwise zero-sized while still allowing request_firmware() to return successfully.
4. Repeatedly trigger the firmware download/error path.
5. Accumulate unreleased firmware resources in kernel memory.
6. Cause service degradation, Bluetooth driver failure, system instability, or denial of service.

How to detect it

There are no public, CVE-specific exploitation indicators provided and the vulnerability is not known to be exploited in the wild. To determine whether exploitation or attempted triggering occurred, review kernel logs, system journal entries, audit logs, and endpoint telemetry for repeated Bluetooth firmware-loading failures, hci_ll driver errors, sudden memory pressure, kernel warnings, hangs, or reboots. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, auditd records for writes to `/lib/firmware`, package/file integrity monitoring for Bluetooth firmware files, and EDR telemetry showing users or processes repeatedly loading/unloading Bluetooth modules or modifying firmware content. Investigate systems showing a combination of invalid or zero-length Bluetooth firmware files, repeated hci_ll initialization failures, and progressive memory exhaustion or denial-of-service symptoms.

• drivers/bluetooth/hci_ll.c
• download_firmware()
• request_firmware()
• release_firmware()
• hci_ll
• /lib/firmware
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• dmesg
• Bluetooth: hci_ll
• firmware: failed to load
• Direct firmware load for
• size 0
• No data
• Bluetooth firmware
• hci_ll: download_firmware

What your security team should do

• Prioritize kernel updates for systems that allow local shell access, shared user access, physical access, or workloads that may interact with Bluetooth devices or firmware-loading paths.
• Confirm all affected systems reboot into a fixed kernel after patch deployment.
• If Bluetooth is not required, disable Bluetooth services and prevent affected Bluetooth modules from loading as a temporary mitigation.
• Restrict write access to firmware directories and monitor for unexpected changes to Bluetooth firmware files.
• Add monitoring for repeated Bluetooth firmware load failures, hci_ll driver errors, abnormal kernel memory pressure, and unexplained host reboots or hangs.
• Track vendor advisories for exact fixed kernel package versions because no fixed versions were provided in the input.
• Treat this as lower exploitation urgency than actively exploited KEV items, but include it in routine kernel maintenance due to potential availability impact.