HowToFixMe
● Local memory leak

How to Fix CVE-2026-43069: Linux Kernel hci_ll Bluetooth Firmware Leak

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Last verified: 2026-05-25

CVE-2026-43069 is a memory leak in the Linux kernel's hci_ll Bluetooth driver: when download_firmware() in drivers/bluetooth/hci_ll.c loads a firmware blob that turns out to be empty or zero-length, the function bails out without freeing it, so a little kernel memory is lost every time. The fix is a one-line cleanup that ships in the patched stable kernels listed below. The right remediation here is a kernel upgrade, not an application or Windows patch, so this page sticks to what actually moves the needle for a kernel driver flaw.

⚡ At a glance
ProductLinux kernel — hci_ll Bluetooth driver (drivers/bluetooth/hci_ll.c)
SeverityNo CVSS in the Linux CNA record. Mechanism is a local kernel memory leak (resource exhaustion), not remote code execution.
Actively exploited?No — not on CISA KEV, no public exploit linked
AffectedKernels from 4.12 up to (but not including) the patched point releases below
Fixed in5.10.253, 5.15.203, 6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11, and mainline 7.0
TypeMissing release of resource on an error path (firmware leak)
Attacker requirementLocal; triggered through the firmware-load error path of a TI Bluetooth controller

Exploitation status

As of this writing, CVE-2026-43069 does not appear on the CISA KEV catalog of actively-exploited flaws — no confirmed real-world exploitation has been catalogued by CISA. Absence from KEV is not reassurance: the catalog frequently lags live exploitation, so treat the patch on its normal severity timeline.

Public exploit availability: there is no public exploit or Metasploit module in the listed references at present. Absence of a published exploit does not mean none exists privately, so keep the risk rating realistic.

What is CVE-2026-43069?

This is a kernel-side resource leak. The affected file is drivers/bluetooth/hci_ll.c, the driver for Texas Instruments Bluetooth controllers that talk to the host over a UART (the "ll" stands for the TI low-level HCI protocol). You find this hardware on a lot of ARM single-board computers, BeagleBone-style boards, and some embedded and automotive Linux systems, where the Bluetooth chip is wired straight into a serial line rather than sitting on USB.

During controller bring-up the driver calls request_firmware() to pull in the patch blob the TI chip needs. The static analyzer Smatch flagged the bug: in download_firmware(), if request_firmware() succeeds but the returned firmware is invalid — no data, or a zero-length blob — the function returns early without ever calling release_firmware(). That blob stays allocated. Nothing frees it. Each time the path is hit, the kernel quietly loses that chunk of memory.

It is, in plain terms, a missing-cleanup bug on an error path. The kind of thing that does not crash anything on the first hit but slowly bleeds memory if the trigger repeats. The official one-line fix is exactly what you would guess: call release_firmware() before returning when the firmware loaded but its contents are invalid. Nothing about the device's behaviour changes — the leak just stops.

Because the trigger is a local firmware-load error and not a network packet, there is no remote attack surface here. No listening port, no parser fed by an attacker over the wire. That matters for how you prioritise it, and it is why the generic "internet-facing, rotate your secrets" advice you see on a lot of CVE pages simply does not apply to this one.

Why this CVE matters

Let me set expectations honestly. This is not a dramatic CVE. The Linux CNA record assigns no CVSS score, there is no CISA KEV entry, and no public exploit is linked. The realistic worst case is resource exhaustion: on a device where the hci_ll firmware load fails repeatedly — a flaky board, a bad or missing firmware file that the driver keeps retrying, a controller that resets in a loop — the leak adds up over hours or days until the system is short on kernel memory. On a small embedded box with 512 MB of RAM, that is a real stability problem long before it would matter on a beefy server.

The integrity and confidentiality impact is essentially nil. Nobody reads your data through a firmware leak. What you lose is availability and predictability, which on an always-on embedded device or a fleet of identical boards is exactly the kind of slow-burn fault that is miserable to diagnose in the field. I have chased "why does this gateway run out of memory after a week" bugs that turned out to be a leak this size, and the answer is never obvious from the symptom.

So treat it as a normal-priority maintenance item. Roll it in with your regular kernel updates. The only group that should bump it up the queue is anyone shipping TI-Bluetooth boards in the field where a memory leak means a service call.

Am I affected?

Two conditions both have to be true. First, your kernel is in the affected range: introduced in 4.12, present until the patched point releases. Second, the hci_ll driver actually loads — which only happens on systems with a TI UART Bluetooth controller. A cloud VM, a typical x86 laptop with a USB or PCIe Bluetooth/Wi-Fi combo card, or any host with no Bluetooth at all will never reach the leaking code, even on a vulnerable kernel.

Check your running kernel version first:

uname -r        # e.g. 6.6.110-generic

Then confirm whether the driver is even in play on this machine:

# Is the hci_ll module loaded right now?
lsmod | grep -i hci_ll

# Is it built into / available in this kernel?
modinfo hci_ll 2>/dev/null | head -n 3

Map your version to the fix. The bug is present from 4.12 and resolved in these stable releases: 5.10.253, 5.15.203, 6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11, and mainline 7.0. Find the series you run and compare. If you are on 6.6.120, you are below 6.6.131 and therefore affected; once your distro ships 6.6.131 or later in that series you are covered.

How to fix CVE-2026-43069

The fix is a kernel upgrade. You do not patch an application, you do not run a Windows installer, and there is no standalone package to bump — the code lives inside the kernel image itself. Pull the patched kernel from your distribution and reboot into it.

Ubuntu / Debian

sudo apt-get update
sudo apt-get install --only-upgrade linux-image-$(uname -r | sed 's/-[a-z]*$//')-generic linux-generic
# Or simply take the latest meta-package kernel:
sudo apt-get install --only-upgrade linux-image-generic
uname -r          # before reboot: still old
sudo reboot

After the reboot, uname -r should show a build at or above the patched point release for your series.

RHEL / Rocky / AlmaLinux / Fedora

sudo dnf upgrade kernel
# dnf installs the new kernel alongside the old one; the bootloader entry is added automatically.
sudo reboot

Arch / rolling and embedded builds

# Arch and derivatives:
sudo pacman -Syu linux

# If you build or vendor your own kernel for an embedded board (Yocto, Buildroot, a BSP),
# rebase onto a stable tag at or above your series fix, e.g. v6.6.131, and reflash the kernel image.

For boards where you maintain the kernel yourself, the cleanest path is to take the upstream stable tag that contains the fix for your series rather than backporting the single commit by hand — though the change is small enough (adding the missing release_firmware() call before the early return) that a manual backport is straightforward if you are pinned to a frozen tree.

If you can't patch immediately

There is no config flag that "turns off" this bug, but because the trigger is so specific, you have a real interim option that a network-exploitable flaw would not give you: stop the driver from loading, or stop it from hitting the error path.

# Option A: if this machine does not actually use a TI UART Bluetooth controller,
# blacklist the module so the leaking code never runs.
echo 'blacklist hci_ll' | sudo tee /etc/modprobe.d/cve-2026-43069.conf
sudo rmmod hci_ll 2>/dev/null || true   # unload it now if it is loaded and unused

# Option B: make sure the correct, valid TI firmware blob is actually present,
# so request_firmware() returns real data and the invalid-firmware path is not taken.
ls -l /lib/firmware/ti-connectivity/   # confirm the expected .bts firmware exists and is non-empty

Option A is the strong one when the hardware is absent or Bluetooth is not needed on that box — no driver, no leak. Option B helps on real TI-Bluetooth hardware: the leak fires specifically when the firmware comes back empty or zero-length, so a correct, present firmware file keeps you out of the bug entirely. Neither replaces the kernel update; they just buy time until your maintenance window.

How to verify the fix worked

Verification here is a version check, not a vulnerability scan — there is no service to probe. After rebooting into the new kernel, confirm the running version is at or above the patched release for your series:

uname -r
# Compare against your series fix, e.g. 6.6.131, 6.1.168, 5.15.203, etc.

On a system that actually exercises the driver, you can watch that the leak is gone by trending kernel slab usage across a few controller bring-ups. If the board was leaking on a firmware-error loop before, Slab in /proc/meminfo should now hold steady rather than creeping after each retry:

grep -i slab /proc/meminfo
# Re-check after the device has cycled the firmware-load path a few times.
# Steady Slab across retries = the leak is fixed.

If you run a vulnerability scanner against the host, refresh its feed and confirm it no longer reports CVE-2026-43069 against the kernel build. That is a nice-to-have here, not the primary signal — the kernel version is the source of truth.

Frequently asked questions

Is CVE-2026-43069 being exploited in the wild?

No. It is not on CISA's KEV catalog and the Linux kernel record links no public exploit. The bug is a kernel memory leak on the hci_ll firmware-load error path — a reliability and resource-exhaustion issue, not a remote takeover. Patch it on your normal maintenance schedule.

What is the CVSS score for CVE-2026-43069?

The Linux kernel CNA record does not publish a CVSS base score or vector. Judge it by mechanism: a local memory leak that wastes kernel RAM when the hci_ll firmware download returns invalid data. Check the NVD entry if an analyst score is added later.

Which Linux kernel versions fix CVE-2026-43069?

It was introduced in 4.12 and fixed in stable releases 5.10.253, 5.15.203, 6.1.168, 6.6.131, 6.12.80, 6.18.21 and 6.19.11, plus mainline 7.0. Upgrade to the patched point release for whatever series you run, or to any newer kernel.

Does this affect machines with no Bluetooth hardware?

Practically, no. The leak lives in drivers/bluetooth/hci_ll.c, which drives Texas Instruments Bluetooth controllers over a UART line. If that hardware is absent, the hci_ll module never loads and the vulnerable path is never reached. Patching the kernel is still the clean fix, and you can blacklist the module in the meantime.

Other flaws in this area worth reviewing while you patch this one:

References

Assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.