kernel/git/stable/linux-stable.git/include/net/bluetooth, branch master

Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan

2026-08-24T17:06:49+00:00

For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking. Fixes: 6fef032af009 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()") Reported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e6382a2f53f5fc7453ac Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz

Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference

2026-08-24T17:06:39+00:00

'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value. The following panic happens: [ ] ------------[ cut here ]------------ [ ] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ ] CPU: 0 PID: 15056 Comm: kworker/u9:2 [ ] Workqueue: hci0 hci_rx_work [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eir_has_uuids+0x2d8/0x590 [ ] lr : is_filter_match+0x258/0x320 ... [ ] Call trace: [ ] eir_has_uuids+0x2d8/0x590 [ ] is_filter_match+0x258/0x320 [ ] mgmt_device_found+0x5b0/0xafc [ ] process_adv_report.part.0+0x8c8/0xf14 [ ] hci_le_adv_report_evt+0x338/0x3f0 [ ] hci_le_meta_evt+0x1f0/0x4c8 [ ] hci_event_packet+0x440/0xc9c [ ] hci_rx_work+0x44c/0xaf8 [ ] process_one_work+0x54c/0x103c [ ] worker_thread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] ret_from_fork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]--- Fixes: 2935e556850e ("Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'") Signed-off-by: Pavel Shpakovskiy Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: Use 255 as max event payload length in hci_ev_table[]

2026-08-07T19:40:27+00:00

hci_event_func() validates skb->len against ev->max_len from the entry in hci_ev_table[]. By then, the header has already been stripped by skb_pull(). So the max event payload is 255, but hci_ev_table[] still uses HCI_MAX_EVENT_SIZE (260) for it, which is imprecise. Fix by introducing HCI_MAX_EVENT_PLEN (255) and using it instead. Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_event: Introduce handle_ev_vendor() for HCI_EV_VENDOR

2026-08-07T19:40:27+00:00

Introduce the hook to solve issues below: msft_vendor_evt(), the current handler for all VSEs, is unsuitable since: - many VSEs are not MSFT ones; - it always corrupts the non-MSFT VSEs by calling skb_pull_data() once the MSFT extension is enabled. Several issues are caused by many transport drivers pre-processing VSEs in their RX path, often an IRQ-disabled atomic context. Take the two typical cases below as examples: Case 1: // no btmon log, no way to reach userspace Step 1: handle and free @original_skb directly Case 2: // hurts performance and consumes GFP_ATOMIC memory Step 1: cloned_skb = skb_clone(original_skb, GFP_ATOMIC); // the VSE is handled here Step 2: handle and free @cloned_skb Step 3: hci_recv_frame(hdev, original_skb); // already handled, but re-enters the stack's event-handling path Step 4: hci_event_packet(hdev, original_skb); Fix by introducing the hook with usage: 1) the transport driver registers the hook for VSEs of interest; 2) the stack calls it in process context, handling the VSE like any other event: - if interested, handle the VSE - no need to free it - and return true; - otherwise return false. Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_core: Introduce __hci_reset_dev() with a hardware error code

2026-08-07T19:40:26+00:00

hci_reset_dev() injects a constant hardware error code 0x00 to restart the device. But a transport driver may need a different error code. Fix by introducing __hci_reset_dev(hdev, hw_err_code), which will be used by a follow-up patch. Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: coredump: Expose header size and end marker to drivers

2026-08-07T19:40:26+00:00

To separate the coredump header and data far more easily, give a vendor driver the option to pad its header to a fixed size, by moving the header size limit and ending marker to coredump.h: - HCI_DEVCD_HDR_SIZE_MAX: the max header size - HCI_DEVCD_HDR_END_MARKER: the header-ending marker Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: add annotations for l2cap_data locking context

2026-08-07T19:38:32+00:00

Add context analysis annotations for hci_conn::l2cap_data locking. Also add necessary lockdep_assert_held() and __must_hold annotations to prove the access is safe. The access in smp_conn_security() is supposed to be guarded by the caller holding lock that blocks concurrent l2cap_conn_del() eg. hdev->lock, conn->lock or chan->lock. Mark unsafe as can't be automatically checked now. Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Add MGMT Load Connection Subrate command

2026-08-07T19:38:32+00:00

Add MGMT_OP_LOAD_CONN_SUBRATE (0x005C) command to load per-device connection subrate parameters when the SCI feature is supported. Add MGMT_EV_CONN_SUBRATE (0x0033) event to notify userspace when connection rate changes occur via the LE Connection Rate Change HCI event. Add subrate fields (subrate_min, subrate_max, max_latency, cont_num) to struct hci_conn_params to store the loaded subrate parameters, and the corresponding le_rate_* fields to struct hci_conn to track the parameters currently in use. When a single entry is loaded for an already-connected central, or on connection completion, the LE Connection Rate Request procedure is initiated to apply the parameters. Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Add MGMT Shorter Connection Interval setting

2026-08-07T19:38:32+00:00

Add MGMT_SETTING_SCI (bit 25) to advertise support for the Shorter Connection Interval (SCI) feature. It is reported in the supported settings whenever the controller is SCI capable, and in the current settings whenever LE is enabled and the controller is SCI capable (SCI has no separate enable command, so it is a passive capability). Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Add support for Shorter Connection Interval (SCI) feature

2026-08-07T19:38:31+00:00

Add HCI command, event and feature bit definitions for the Bluetooth 6.2 Shorter Connection Interval feature: Commands: - HCI_OP_LE_CONN_RATE (0x20a1) - Connection Rate Request - HCI_OP_LE_SET_DEF_RATE (0x20a2) - Set Default Rate Parameters - HCI_OP_LE_READ_CONN_INTERVAL (0x20a3) - Read Min Supported Connection Interval Events: - HCI_EVT_LE_CONN_RATE_CHANGE (0x37) - Connection Rate Change Feature bits: - HCI_LE_SCI - Shorter Connection Intervals - HCI_LE_SCI_HOST - Shorter Connection Intervals (Host Support) During controller init, when SCI is supported: - Set Shorter Connection Intervals (Host Support) feature via LE Set Host Feature - Read Minimum Supported Connection Interval - Set Default Rate Parameters The Connection Rate Change event handler updates the connection interval, latency and supervision timeout on the hci_conn. Signed-off-by: Luiz Augusto von Dentz