CVE-2025-40308: Linux Bluetooth BCSP Receive Fix and Mitigation Guide

The Linux kernel vulnerability tracked as CVE-2025-40308 is a defect in the Bluetooth BCSP (BlueCore Serial Protocol) receive path that can trigger a kernel null-pointer dereference and crash when bcsp_recv processes data while the underlying protocol has not yet been registered; the issue has been fixed upstream and administrators should prioritize kernel updates or apply mitigations on affected embedded and IoT hosts.

Background / Overview​

Bluetooth host stacks expose multiple transport layers; one of them is BCSP (BlueCore Serial Protocol), commonly used by UART-connected Bluetooth controller chips and some embedded platforms. The kernel driver implements a receive handler, bcsp_recv, which expects the BCSP protocol to be registered before processing incoming bytes. In the vulnerable code path, bcsp_recv could be invoked even when the HCI_UART_REGISTERED flag was not set, causing the handler to dereference a NULL pointer and crash under KASAN (Kernel Address SANitizer) or in production kernels. The canonical symptom is a kernel log showing a KASAN null-pointer-deref originating from drivers/bluetooth/hci_bcsp.c with a stack trace that ties into the tty/ioctl and HCI UART receive paths. This is a classic robustness bug in a transport glue layer: the kernel received data from a tty line discipline or uart driver and attempted to hand it to the Bluetooth bcsp logic before the driver had completed registration. The fix implemented upstream is a defensive check: ensure HCI_UART_REGISTERED is set before handling data — if it is not, bcsp_recv should return -EUNATCH instead of proceeding.

---

What the code-level failure looks like​

The observable trace and root cause​

• The crash presents as a KASAN message such as: KASAN: null-ptr-deref in range [...] RIP: bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590.
• The call stack typically includes the HCI UART receive/line-discipline path (hci_uart_tty_receive) and common TTY ioctl/receive frames, meaning the bug is triggered by data arriving over the UART/TTY transport to the Bluetooth HCI uplink.

At root, the flaw is a missing precondition check: the receive handler does not verify that the BCSP/HCI_UART state machine has reached the "registered" state before dereferencing protocol-specific pointers. When the registration flag is absent, internal pointer fields remain NULL and the dereference is fatal.

The upstream corrective change​

The upstream correction is intentionally minimal and conservative: add a test for HCI_UART_REGISTERED at the start of the receive path and bail out with -EUNATCH if the protocol is not registered. This avoids race conditions between registration and early-arriving bytes and aligns with defensive patterns used elsewhere in the HCI UART code. Public vulnerability trackers and the OSV/NVD entries document the fix requirement and reference upstream commits.

---

Who and what is affected​

• Affected component: Linux kernel Bluetooth BCSP (driver file drivers/bluetooth/hci_bcsp.c) and systems that use BCSP over UART for HCI transport.
• Typical platforms at risk: Embedded Linux devices, IoT gateways, routers, development boards, and some desktops or laptops that use UART-attached Bluetooth controllers or where BCSP line-discipline modules are built into the kernel. Systems that build the kernel with BCSP/HCI UART support (notably using the hci_uart/bcsp line discipline) are the primary population.
• Attack prerequisites: An attacker (or misbehaving device) must cause data to be delivered into the bcsp receive path before registration completes; this can happen over a physical UART interface, through crafted local I/O (TTY/IOCTL), or during racey device initialization sequences. Network attackers over RF alone are not the typical vector unless they control a local UART-connected peer or can manipulate the physical transport.

In short: this CVE is most relevant to maintainers of embedded kernels and device vendors who expose HCI over UART; commodity desktop distributions may be affected only when those modules are enabled.

---

Impact and exploitability analysis​

Immediate impact: denial of service​

The directly observed effect is a NULL pointer dereference leading to a kernel oops, KASAN report, and frequently a panic or reboot on production kernels. That outcome is an availability failure: device instability, crashes, or hangs. There is no public evidence that this specific null-dereference has been abused to achieve remote code execution or kernel privilege escalation. The practical risk is therefore availability disruption rather than a confirmed confidentiality or integrity breach.

Could this lead to worse outcomes?​

While a simple NULL dereference itself is a crash-only symptom, kernel reliability bugs in low-level transport code can sometimes serve as a reconnaissance or stepping-stone when combined with other weaknesses. Historically, Bluetooth and RFCOMM subsystems have hosted a variety of memory-safety and synchronization bugs; defenders should treat such kernel-level defects seriously because additional conditions or adjacent bugs can expand impact. However, for CVE-2025-40308 the public record indicates a straightforward precondition omission fixed by a small defensive check rather than a complex memory-corruption primitive.

Exploitability in practice​

• Attack complexity: Low-to-moderate if local access to the UART/TTY transport is available.
• Remote exploitability: Unlikely without intermediate physical access to the UART/TTY, a malicious device connected to the host, or a privileged local process that can issue TTY IOCTLs.
• Prevalence in the field: Depends on the number of devices running kernels that include drivers/bluetooth/hci_bcsp.c with BCSP and HCI UART enabled and without the upstream fix applied. Embedded appliances and long-tail IoT devices are the highest-risk populations because those systems often run older, rarely-updated kernel trees.

---

Verification and cross-checks (what we validated)​

Multiple independent vulnerability databases recorded the defect and the high-level remediation guidance:

• The NVD entry for CVE-2025-40308 describes the KASAN null-pointer dereference and recommends ensuring the HCI_UART_REGISTERED flag is present before processing data.
• The Debian/OSV and SUSE security trackers mirror the upstream description and note the same fix semantics.
• Public CVE aggregators (OpenCVE, CVE Details) list the same call trace and note upstream commits that backport the fix to stable kernel branches; they reference the kernel stable commits that implement the defensive check.

Note: attempts to view some upstream git commit pages directly can be blocked by client restrictions (some kernel mirrors require a browser). The vulnerability trackers above already point to the accepted upstream patch series and stable branch merges, and those trackers are consistent with one another.

---

How to detect if you are vulnerable​

The following steps help triage whether a host is affected and whether the buggy codepath has been hit:

• Determine whether the kernel has BCSP/HCI UART support:
• Check loaded modules: lsmod | grep hci_uart
• Inspect kernel config (where available): grep -E 'CONFIG_BT_HCIUART|CONFIG_BT_BCSP' /boot/config-$(uname -r)
• Search kernel logs for the signature KASAN/NPE trace:
• journalctl -k | grep -i 'bcsp_recv|hci_bcsp|KASAN: null-ptr-deref'
• dmesg | grep -E 'bcsp_recv|hci_bcsp|KASAN'
  These log lines mirror those shown in vulnerability databases and indicate that the precondition check was missing.
• If you build kernels from source: search the source tree for bcsp_recv or the use of HCI_UART_REGISTERED in drivers/bluetooth/hci_bcsp.c to verify whether the defensive check exists in your tree.
• For embedded product maintainers: examine firmware build artifacts and kernel package changelogs to see whether the vendor has backported the upstream fix into their shipped kernel.

File-system and logging artifacts (kernel oops, KASAN traces) are the most straightforward detection signals; collecting persistent crash logs or enabling kdump on critical devices will preserve evidence for later analysis.

---

Immediate mitigations and recommended remediation​

The preferred remediation is to apply a kernel update that contains the upstream fix and reboot into the patched kernel. Where immediate patching is challenging, apply the compensating controls described below.

Priority remediation (recommended)​

• Install vendor-supplied kernel updates that include the backported fix or upgrade to a mainline/stable kernel that contains the patch; then reboot devices. Upstream trackers indicate the upstream fix has been merged into stable branches and backports are available.

Short-term compensations (if patching is delayed)​

• Unload or blacklist the HCI UART / BCSP driver (temporary):
• Unload module: modprobe -r hci_uart or modprobe -r bluetooth depending on packaging.
• Prevent module load: create /etc/modprobe.d/blacklist-hci_uart.conf with blacklist hci_uart and rebuild initramfs if necessary.
  Note: on systems where the HCI UART drivers are built-in (not modular), unloading is not possible without a reboot into a patched kernel.
• Disable Bluetooth services and user-space components on devices where Bluetooth is not required (e.g., mask the bluetooth service in systemd on Linux: systemctl stop bluetooth && systemctl mask bluetooth), acknowledging the operational impact.
• Harden local access to TTY/IOCTL paths: restrict which users or processes can access the relevant device nodes to reduce the likelihood of a local unprivileged process triggering the race. Use standard host hardening (file permissions, AppArmor/SELinux, containerization) to limit exposure.

For device OEMs and embedded vendors​

• Backport the minimal defensive check into your kernel tree, rebuild, and push firmware/kernel updates to devices. The upstream fix is small and low-risk to backport but must be compiled and validated against device-specific kernel configurations and hardware.
• Validate in a test harness that early initialization sequences (hotplug, early UART data) no longer trigger the crash.

---

Detection, monitoring, and hunting guidance​

• Alert on kernel log signatures:
• Monitor for KASAN: null-ptr-deref referencing bcsp_recv, hci_bcsp.c, or call stacks containing hci_uart_tty_receive. These are the most load‑bearing telemetry lines indicating an attempted or successful trigger.
• Collect and centralize kernel panics and oops output via persistent logging or kdump. Preserve crash dumps for forensic analysis and vendor triage.
• For managed fleets, add a CVE-to-package mapping in your patch automation and ensure the specific kernel package builds for each node are checked against distributor advisories (Debian, SUSE, vendor kernels) rather than relying on generic CVE strings.

---

Why this matters operationally​

• Small code changes can have outsized impact: A single missing flag check in a low-level receive handler can propagate into kernel space and crash the entire host. This vulnerability is an object lesson in how transport-layer bookkeeping mistakes translate into availability risks for real devices.
• Embedded and IoT update lag: Many affected devices are hard to patch rapidly (certification cycles, on-device firmware update processes), so the practical window of exposure can be long even though the fix is small. Prioritizing gateways and always-on BLE infrastructure reduces downstream risk.
• Not all Bluetooth features are equally common: BCSP/HCI over UART is more common in embedded ecosystems than on consumer desktops; therefore risk prioritization should focus on the device classes that actually use the affected transport.

---

Practical checklists​

For system administrators (first 24–72 hours)​

• Inventory hosts with Bluetooth/HCI UART support and identify kernel versions: uname -r and lsmod | grep hci_uart.
• Search logs for bcsp_recv and KASAN null-deref traces.
• If immediate patching is impractical, temporarily disable Bluetooth/HCI UART modules on non-essential hosts and schedule firmware/kernel upgrades for embedded appliances.

For embedded device vendors​

• Merge the upstream fix into your kernel tree and rebuild device images.
• Run device-specific tests that exercise early UART initialization, hot-unplug, and other lifecycle events.
• Push firmware updates through your validated rollout channels and publish an advisory describing affected builds and mitigation options.

For security operations teams​

• Add detection rules for the KASAN/oops signatures and include telemetry collection for kernel messages.
• Treat unexplained reboots or kernel oopses on Bluetooth-enabled gateways as high priority and capture crash dumps for analysis.

---

Strengths and limitations of the public record​

• Strengths:
• Multiple independent vulnerability trackers (NVD, OSV/DEBIAN, SUSE) and CVE aggregators report the same failure mode and mitigation approach, giving high confidence in the defect’s existence and the correct remediation vector.
• The upstream fix is small and straightforward to apply or backport, which reduces regression risk for vendors.
• Limitations and cautionary notes:
• Publicly available exploit details and proof-of-concept code are not provided and there are no credible reports of widescale in-the-wild exploitation at the time of publication; however, absence of public PoC does not equate to absence of risk in certain local or targeted scenarios. Treat exploitation claims conservatively until validated.
• For devices with integrated (non-modular) BCSP/HCI UART support, temporary workarounds are limited—updates require full firmware/kernel replacement and reboot.

---

Conclusion​

CVE-2025-40308 is a robustness bug in the Linux Bluetooth BCSP receive path where bcsp_recv processed data without verifying that the BCSP protocol was registered, leading to a NULL pointer dereference and kernel crash. The defensive fix is simple — ensure the HCI_UART_REGISTERED flag is set and return -EUNATCH if not — and it has already been merged upstream and documented by multiple vulnerability databases. Administrators, IoT vendors, and kernel maintainers should treat this as a patch-first item for affected systems: apply vendor or upstream kernel updates, or (when updates cannot be immediately deployed) disable or blacklist the HCI UART / BCSP components and tighten local access to TTY/IOCTL interfaces until a patched image is available.

---

If you manage embedded or IoT fleets, prioritize gateways and devices that bridge BLE to IP or that expose UART-connected Bluetooth controllers. For general Linux hosts, map the CVE to your distribution’s kernel package and schedule a controlled rollout of the patched kernel while monitoring kernel logs for the characteristic KASAN null-deref signature in bcsp_recv.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center