CVE-2026-46138

What it actually does

This Linux kernel Bluetooth flaw is an out-of-bounds read in the HCI event handler for LE Create BIG Complete events. If the Bluetooth controller reports fewer BIS handles than the host expects, including num_bis=0, the kernel can read past the valid flexible array into adjacent heap memory. The invalid handle values are rejected, leaving the connection in BT_BOUND state; the handler then repeatedly finds the same connection and enters an infinite loop while holding the Bluetooth device lock. The practical impact is a kernel-level denial of service affecting Bluetooth processing and potentially broader system responsiveness, with possible kernel heap information exposure characteristics from the out-of-bounds read.

Why it matters to the business

Systems using affected Linux kernel Bluetooth functionality may become unstable or unresponsive when processing malformed Bluetooth LE BIG/BIS events, disrupting services that depend on Bluetooth, embedded connectivity, kiosks, mobile/edge devices, workstations, or appliances using LE Audio or related Bluetooth features. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but it is kernel-level and can cause high operational impact where Bluetooth is enabled and reachable.

How an attack unfolds

An attacker must be in a position to influence Bluetooth HCI events delivered to the Linux host, such as through a malicious, compromised, or manipulated Bluetooth controller path, or adjacent Bluetooth attack conditions that result in malformed LE BIG completion data being processed. The attacker causes the host to receive a LE_Create_BIG_Complete event where num_bis is smaller than the number of BT_BOUND connections associated with the BIG handle, or is zero. The vulnerable kernel handler continues iterating over expected bound connections and reads ev->bis_handle entries beyond the valid event payload. Because the out-of-bounds values usually do not represent valid HCI connection handles, the target connection remains bound and is found again, causing an infinite loop while the Bluetooth device lock is held. This can hang Bluetooth processing and may contribute to system stalls, watchdog events, or denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Bluetooth hci_event LE Create BIG Complete handler. No exact fixed package versions were provided in the input, so use the appropriate distribution or vendor kernel advisory for this CVE and install the fixed kernel package for each affected platform. Reboot into the fixed kernel after patching and remove or de-prioritize older vulnerable kernels where operationally possible. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blocking Bluetooth service startup, removing or blacklisting Bluetooth kernel modules where acceptable, disabling Bluetooth in firmware/BIOS for managed endpoints, and restricting physical proximity and pairing opportunities for systems that must keep Bluetooth enabled.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r and comparing it with the vendor-fixed kernel version for the platform. Validate that Bluetooth is disabled or unavailable on systems where mitigation was chosen instead of patching. For source-based kernels, verify that hci_le_create_big_complete_evt() bounds-checks the BIS handle index against ev->num_bis and terminates the BIG/error path when not all BIS handles can be set up correctly. Review boot logs after reboot to confirm the fixed kernel is active and the Bluetooth stack initializes normally. Where safe and approved, perform non-malicious functional testing of Bluetooth LE/LE Audio workflows to ensure no regression in expected Bluetooth operation.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and a kernel build containing the vulnerable hci_le_create_big_complete_evt() logic.
2. Establish a position that can influence Bluetooth LE BIG/BIS setup or HCI event delivery to the host, such as a malicious controller, compromised firmware path, or adjacent Bluetooth interaction capable of triggering malformed completion handling.
3. Trigger or induce creation of BT_BOUND connections for a BIG handle on the host.
4. Deliver a malformed LE_Create_BIG_Complete event with fewer bis_handle entries than the number of bound connections, or with num_bis set to zero.
5. Cause the kernel Bluetooth event handler to read beyond the valid bis_handle array and reject invalid handles.
6. Leave the connection in BT_BOUND state so the lookup returns the same connection repeatedly.
7. Force the handler into an infinite loop while holding hci_dev_lock, resulting in Bluetooth subsystem lockup and possible system-level denial of service.

How to detect it

To assess possible prior exploitation, review kernel and system logs from systems with Bluetooth enabled for unexplained Bluetooth lockups, watchdog soft lockups, RCU stalls, hung tasks, or kernel stack traces involving Bluetooth HCI event processing. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, endpoint telemetry, and fleet health records showing sudden reboots or hangs. Search around timestamps of Bluetooth pairing, LE Audio, ISO/BIG/BIS activity, controller resets, or user reports of Bluetooth failure. If kernel crash dumps are available, inspect stacks for hci_le_create_big_complete_evt(), hci_event_packet(), hci_rx_work(), hci_conn_hash_lookup_big_state(), or hci_conn_set_handle(). Absence of these artifacts does not prove non-exploitation because the vulnerable path may cause a live lock rather than a clean crash or explicit log entry.

• hci_le_create_big_complete_evt
• hci_conn_hash_lookup_big_state
• hci_conn_set_handle
• hci_event_packet
• hci_rx_work
• Bluetooth:
• LE Create BIG Complete
• Create BIG Complete
• bis_handle
• num_bis
• BT_BOUND
• watchdog: BUG: soft lockup
• BUG: soft lockup
• INFO: task
• blocked for more than
• rcu: INFO: rcu_preempt detected stalls
• rcu: INFO: rcu_sched detected stalls
• Bluetooth: hci0
• Bluetooth: hci1
• Bluetooth: hci2

What your security team should do

• Prioritize patching Linux systems with Bluetooth enabled, especially endpoints, embedded systems, appliances, kiosks, mobile/edge devices, and systems using Bluetooth LE Audio or related LE ISO/BIG functionality.
• Inventory systems with active Bluetooth adapters and running affected Linux kernels; treat systems with Bluetooth disabled or absent as lower immediate exposure.
• If patching is delayed, disable Bluetooth services and kernel module loading where business functions do not require Bluetooth.
• Monitor kernel logs for Bluetooth-related hangs, watchdog soft lockups, RCU stalls, and stack traces referencing hci_le_create_big_complete_evt or Bluetooth HCI event handling.
• Confirm vendor fixed kernel availability because no exact fixed versions were provided; track distribution advisories rather than relying solely on upstream kernel naming.
• Because the issue is not KEV-listed, not associated with ransomware in the provided data, and has low EPSS, prioritize based on Bluetooth exposure and operational criticality rather than broad emergency internet-facing remediation.