linux.git/net/bluetooth/hci_event.c, branch master

Bluetooth: mgmt: Translate HCI reason in Device Disconnected event

2026-07-13T14:10:13Z

MGMT_EV_DEVICE_DISCONNECTED carries a reason field which is defined to be one of MGMT_DEV_DISCONN_* (0x00..0x05). hci_disconn_complete_evt() converts the HCI error with hci_to_mgmt_reason(), but two other paths pass the raw HCI error straight through: hci_cs_disconnect() -> cp->reason mgmt_connect_failed() -> status The latter is reached whenever the adapter is powered off or suspended: hci_disconnect_all_sync() aborts every link with HCI_ERROR_REMOTE_POWER_OFF, hci_disconnect_sync() deliberately does not wait for HCI_EV_DISCONN_COMPLETE for that reason, so that hci_abort_conn_sync() finishes the connection off through hci_conn_failed() instead. As a result userspace sees an out of range reason: @ MGMT Event: Device Disconnected (0x000c) plen 8 BR/EDR Address: 8C:A9:6F:2C:51:46 Reason: Reserved (0x15) bluetoothd: btd_bearer_disconnected() Unknown disconnection value: 21 bluetoothd: device_disconnected() Unknown disconnection value: 21 Export hci_to_mgmt_reason() and use it in both places, so that a power off is reported as MGMT_DEV_DISCONN_REMOTE rather than as the raw HCI_ERROR_REMOTE_POWER_OFF (0x15). Fixes: d47da6bd4cfa ("Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED") Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Signed-off-by: Mikhail Gavrilov Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Add SPDX id lines to some source files

2026-06-11T18:24:41Z

Many bluetooth source files are missing SPDX-License-Identifier lines. Add appropriate IDs to these files, and remove other license lines from the headers. Leave the warranty disclaimer in files where the license ID is GPL-2.0 but the wording of the disclaimer is slightly different from that of the GPL v2 disclaimer. It is not different enough to cause licensing conflicts, but is kept to honor the original contributors' legal intent. Signed-off-by: Tim Bird Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING

2026-06-11T18:24:40Z

When hci_inquiry_complete_evt is called between le_scan_disable and le_set_scan_enable_complete and no remote name needs to be resolved, the interleaved discovery with SIMULTANEOUS quirk gets stuck in DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry state. No one sets DISCOVERY_STOPPED in this process. Add state check in le_set_scan_enable_complete and change state if the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell Vostro 13. Discovering disabled MGMT Event below is reported when running into the above condition. @ MGMT Command: Start Discovery (0x0023) {0x0001} [hci0] 10885.970873 Address type: 0x07 BR/EDR LE Public LE Random ... < HCI Command: LE Set Extended Scan Enable #38205 [hci0] 10886.131438 Extended scan: Enabled (0x01) Filter duplicates: Enabled (0x01) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Command Complete (0x0e) plen 4 #38206 [hci0] 10886.133295 LE Set Extended Scan Enable (0x08|0x0042) ncmd 2 Status: Success (0x00) @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10886.133414 Address type: 0x07 BR/EDR LE Public LE Random Discovery: Enabled (0x01) < HCI Command: Inquiry (0x01|0x0001) plen 5 #38207 [hci0] 10886.133528 Access code: 0x9e8b33 (General Inquiry) Length: 10.24s (0x08) Num responses: 0 > HCI Event: Command Status (0x0f) plen 4 #38208 [hci0] 10886.141333 Inquiry (0x01|0x0001) ncmd 2 Status: Success (0x00) ... < HCI Command: LE Set Extended Scan Enable #38242 [hci0] 10896.381802 Extended scan: Disabled (0x00) Filter duplicates: Disabled (0x00) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Inquiry Complete (0x01) plen 1 #38243 [hci0] 10896.383419 Status: Success (0x00) > HCI Event: Command Complete (0x0e) plen 4 #38244 [hci0] 10896.394378 LE Set Extended Scan Enable (0x08|0x0042) ncmd 2 Status: Success (0x00) @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497 LE Address: 88:12:AC:92:43:69 RSSI: -101 dBm (0x9b) Flags: 0x00000004 Not Connectable Data length: 8 Company: Xiaomi Inc. (911) Data[0]: 16-bit Service UUIDs (complete): 1 entry Xiaomi Inc. (0xfdaa) @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10896.394506 Address type: 0x07 BR/EDR LE Public LE Random Discovery: Disabled (0x00) Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync") Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: fix memset typo

2026-05-06T20:27:29Z

hci_le_big_sync_established_evt() currently does: conn->num_bis = 0; memset(conn->bis, 0, sizeof(conn->num_bis)); sizeof(conn->num_bis) is wrong - it would make sense to either use conn->num_bis (before setting that to 0) or sizeof(conn->bis). Fix it by using sizeof(conn->bis), the least intrusive change. Luckily, nothing actually depends on this memset() working properly: Nothing seems to ever read from conn->bis beyond conn->num_bis, and when conn->num_bis is increased, the corresponding elements of conn->bis are initialized. So I think this line could also just be removed. This is a purely theoretical fix and should have no impact on actual behavior. Fixes: 42ecf1947135 ("Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending") Signed-off-by: Jann Horn Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt

2026-05-06T20:18:22Z

hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access. When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held. Fix this by terminating the BIG if in case not all BIS could be setup properly. Fixes: a0bfde167b50 ("Bluetooth: ISO: Add support for connecting multiple BISes") Cc: stable@vger.kernel.org Signed-off-by: ZhiTao Ou Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: fix potential UAF in SSP passkey handlers

2026-04-13T13:19:42Z

hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path. Fixes: 92a25256f142 ("Bluetooth: mgmt: Implement support for passkey notification") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey Signed-off-by: Luiz Augusto von Dentz

Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER

2026-04-13T13:18:16Z

When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock. Fixes: 70c464256310 ("Bluetooth: Refactor connection request handling") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt

2026-04-01T20:46:55Z

hci_conn lookup and field access must be covered by hdev lock in hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage. Fixes: 95118dd4edfec ("Bluetooth: hci_event: Use of a function table to handle LE subevents") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: move wake reason storage into validated event handlers

2026-04-01T20:44:15Z

hci_store_wake_reason() is called from hci_event_packet() immediately after stripping the HCI event header but before hci_event_func() enforces the per-event minimum payload length from hci_ev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs. Rather than duplicating skb parsing and per-event length checks inside hci_store_wake_reason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hci_store_wake_reason() into a small helper that only stores an already-validated bdaddr while the caller holds hci_dev_lock(). Use the same helper after hci_event_func() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address. Annotate the helper with __must_hold(&hdev->lock) and add lockdep_assert_held(&hdev->lock) so future call paths keep the lock contract explicit. Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(), hci_sync_conn_complete_evt(), le_conn_complete_evt(), hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(), hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and hci_le_past_received_evt(). Fixes: 2f20216c1d6f ("Bluetooth: Emit controller suspend and resume events") Cc: stable@vger.kernel.org Signed-off-by: Oleh Konko Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Fix using PHYs bitfields as PHY value

2026-01-29T18:27:47Z

This renames the PHY fields in bt_iso_io_qos to PHYs (plural) since it represents a bitfield where multiple PHYs can be set and make the same change also to HCI_OP_LE_SET_CIG_PARAMS since both c_phy and p_phy fields are bitfields. This also fixes the assumption that hci_evt_le_cis_established PHYs fields are compatible with bt_iso_io_qos, they are not, the fields in hci_evt_le_cis_established represent just a single PHY value so they need to be converted to bitfield when set in bt_iso_io_qos. Signed-off-by: Luiz Augusto von Dentz