summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-08-07Bluetooth: hci_sync: Disable legacy instance's ext adv before setup snapshotMuhammad Saheed1-0/+30
hci_setup_ext_adv_instance_sync(...) only disabled HCI_OP_LE_SET_EXT_ADV_ENABLE before setup snapshot in case of non-legacy instances (instance > 0) and never disabled the same for legacy instance (instance == 0). This would lead to failure in setting ext adv params with HCI_ERROR_COMMAND_DISALLOWED (0x0c) error like below, when toggling the discoverable/connectable property of a controller with advertising enabled. ``` $ btmgmt advertising off hci0 Set Advertising complete, settings: powered ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable on hci0 Set Connectable complete, settings: powered connectable ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable off hci0 Set Connectable complete, settings: powered ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt advertising on hci0 Set Advertising complete, settings: powered connectable ssp br/edr le advertising secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable on Set Connectable for hci0 failed with status 0x0a (Busy) $ btmgmt connectable off Set Connectable for hci0 failed with status 0x0a (Busy) $ dmesg ... [ 21.970527] hci0: Opcode 0x2036 [ 21.970529] hci0: opcode 0x2036 plen 25 [ 21.970537] hci0: skb len 28 [ 21.970539] hci0: length 1 [ 21.976099] hci0: result 0x0c [ 21.976105] hci0: end: err -16 [ 21.976114] Bluetooth: hci0: Opcode 0x2036 failed: -16 ``` Signed-off-by: Muhammad Saheed <muhammad.saheed.iam@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_event: fix out-of-bounds read in LE PA report reassemblyLaxman Acharya1-0/+7
hci_le_per_adv_report_evt() is dispatched with a minimum length of sizeof(struct hci_ev_le_per_adv_report), which only covers the fixed part of the event and not the trailing data[] array: struct hci_ev_le_per_adv_report { __le16 sync_handle; __u8 tx_power; __u8 rssi; __u8 cte_type; __u8 data_status; __u8 length; __u8 data[]; } __packed; The handler notifies the ISO layer via hci_proto_connect_ind(), which reaches iso_connect_ind(). That function retrieves the stored event with hci_recv_event_data() and, while reassembling the periodic advertising data, does: memcpy(hcon->le_per_adv_data + hcon->le_per_adv_data_offset, ev->data, ev->length); ev->length is taken directly from the event and is never validated against the amount of data the event actually carries. A controller that reports a length larger than the received event therefore causes the memcpy() to read past the end of the event buffer. The leaked bytes are stored in hcon->le_per_adv_data and can subsequently be read back from user space via getsockopt(BT_ISO_BASE). Validate that the event contains ev->length data bytes before it is consumed, mirroring the check already performed by hci_le_ext_adv_report_evt() and hci_le_adv_report_evt(). Signed-off-by: Laxman Acharya <acharyalaxman8848@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is negativeGuangshuo Li1-0/+3
btmtksdio_setup() calls pm_runtime_use_autosuspend() when runtime PM is supported, but btmtksdio_remove() does not call the matching pm_runtime_dont_use_autosuspend() when removing the device. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call in the remove path before restoring the runtime PM usage reference. This issue was found by manual code inspection. Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255Ali Ahmet Memis1-0/+8
mgmt_hci_cmd_sync() checks that the message length agrees with params_len but puts no upper bound on it. params_len is __le16 while the parameter length in the HCI command header is a u8: struct hci_command_hdr { __le16 opcode; __u8 plen; } __packed; hci_cmd_sync_alloc() assigns one to the other: hdr->plen = plen; if (plen) skb_put_data(skb, param, plen); so a params_len of 256 leaves plen at 0 while all 256 bytes are still appended. The frame handed to the driver then declares no parameters and carries 256 of them. On a length framed transport such as H:4 the controller takes the trailing bytes as the start of the next packet. The mgmt socket MTU is HCI_MAX_FRAME_SIZE, so params_len can reach about 1KB this way. Commit 03f1700b9b4d ("Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commands") only made params_len agree with the message length, a value that fits the message but not the header field is still accepted. Reject params_len that does not fit the header field. Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseqSherry Sun1-4/+30
Power supply to the M.2 Bluetooth device attached to the host using M.2 connector is controlled using the 'uart' pwrseq device. So add support for getting the pwrseq device if the OF graph link is present. Once obtained, pwrseq_power_on() is called to power up the M.2 Bluetooth card. The power sequencer descriptor is obtained via pwrseq_get() with the UART controller device (serdev->ctrl->dev), since the OF graph link is defined on the UART controller node. Also add the explicit pwrseq_put() call in all exit paths, pwrseq_put() already calls pwrseq_power_off() internally, so no separate pwrseq_power_off() call is needed. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: MGMT: free the HCI command when it is cancelledLinmao Li1-5/+8
mgmt_hci_cmd_sync() queues the pending command with a NULL destroy callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. The now-empty done label is replaced by a direct return. Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: MGMT: free the mesh send cancel command when it is cancelledLinmao Li1-2/+7
mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_sync: free the advertising instance on the failure and cancel ↵Linmao Li1-3/+9
paths adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all. Fixes: c249ea9b4309 ("Bluetooth: Move Adv Instance timer to hci_sync") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_conn: fix the SCO setup context lifetimeLinmao Li1-5/+15
hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 ("Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_sync: Fix accept list UAF during suspendChengfeng Ye1-9/+37
hci_update_event_filter_sync() walks hdev->accept_list while sending a synchronous HCI command for each remote-wakeup device. The suspend path holds hdev->req_lock, but accept-list updates are serialized by hdev->lock. Consequently, remove_device() can free the current list entry during the controller wait. The following interleaving causes the use-after-free: hci_update_event_filter_sync() remove_device() fetch accept-list entry hci_set_event_filter_sync() wait for controller response hci_dev_lock() list_del() kfree() hci_dev_unlock() read the freed list.next KASAN reported: BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910 Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10 Workqueue: events vhci_suspend_work Call Trace: hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10 Allocated by task 86: hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 91: kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0 Snapshot the remote-wakeup addresses under hdev->lock. Release the lock before sending HCI commands. Clear the controller event filter before building the snapshot, and skip allocation and the second list traversal when there are no matching entries. This preserves the original filter and scan-state updates without retaining an accept-list node across a controller wait. Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-bluetooth/20260730092331.2069741-1-nicoyip.dev@gmail.com/ Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_event: Use 255 as max event payload length in hci_ev_table[]Zijun Hu2-7/+8
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 <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_event: Introduce handle_ev_vendor() for HCI_EV_VENDORZijun Hu2-1/+11
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 <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btnxpuart: Simplify nxp_set_ind_reset() by __hci_reset_dev()Zijun Hu1-13/+1
nxp_set_ind_reset() injects the non-zero hardware error code BTNXPUART_IR_HW_ERR. Simplify it by __hci_reset_dev(hdev, BTNXPUART_IR_HW_ERR). Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_core: Introduce __hci_reset_dev() with a hardware error codeZijun Hu2-4/+10
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 <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: coredump: Expose header size and end marker to driversZijun Hu2-5/+9
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 <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btintel: Remove redundant (hdr->plen > 0) in btintel_recv_event()Zijun Hu1-2/+1
Drop the check since: - it is already implied by the existing (skb->len > HCI_EVENT_HDR_SIZE) - hdr->plen is then not used by the function at all Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btintel: Fix diagnostics event detectionZijun Hu1-1/+1
For a diagnostics VSE, diagnostics_hdr[] sits at the start of the event payload, skb->data[2], but btintel_recv_event() wrongly guards its memcmp with @len, which is measured from skb->data[3] for the earlier INTEL_BOOTLOADER check. Fix by using (@len + 1) instead, which == (skb->len - HCI_EVENT_HDR_SIZE) exactly. Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support") Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_event: validate LE Set CIG Parameters responseLaxman Acharya Padhya1-2/+4
The Command Complete dispatch validates only the fixed part of the LE Set CIG Parameters response. After that part is pulled from the skb, hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the trailing handle array. Matching num_handles against the command's num_cis does not guarantee that the response contains the advertised handles. A truncated response from a malfunctioning controller can therefore make the handler read beyond the skb data. Validate that the remaining skb data contains all advertised handles. Include this in the existing response validation so malformed responses also follow the established CIG failure handling. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btmrvl: fix event packet length validationMarek Szyprowski1-1/+11
The event length validation added by 65be90af2756 commit used a single check against sizeof(*event), which assumed every event type uses the maximum payload size. Unfortunately event packet length depends on the type of the received event, so it must be checked separately for each event type to avoid rejecting some known well-formed events. Fixes: 65be90af2756 ("Bluetooth: btmrvl: validate event packet lengths") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: add annotations for l2cap_data locking contextPauli Virtanen6-4/+24
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 <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_indPauli Virtanen1-6/+17
hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently. disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work. Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths. Fixes: ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del") Reported-by: syzbot+9c40ad7c6ed7165e46e8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c40ad7c6ed7165e46e8 Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: virtio_bt: avoid OOB read of build info stringHyeongJun An1-2/+6
The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded "%.*s" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 ("Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()"), which fixed the identical pattern. Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver") Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hcli_ldisc: Remove reduntant bracesoshada imalka1-2/+2
Removed a redundant braces for a single if statement Signed-off-by: Oshada Imalka <developerimalka@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_event: fix LE list UAF on resetChengfeng Ye1-0/+2
hci_cc_reset() clears the LE accept and resolving lists without taking hdev->lock. Other command-complete handlers serialize updates to these lists with that lock, and the debugfs readers hold it while walking them. This permits the reset completion and a debugfs read to interleave as follows: hci_rx_work debugfs reader ----------- -------------- lock hdev->lock fetch current entry list_del(entry) kfree(entry) read entry fields The reader then dereferences a freed list entry and may follow its stale next pointer. KASAN reported: BUG: KASAN: slab-use-after-free in white_list_show+0x15f/0x180 Read of size 1 at addr ffff8881015dab16 by task poc/95 Call Trace: white_list_show+0x15f/0x180 seq_read_iter+0x3ff/0x1190 seq_read+0x267/0x3d0 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 Allocated by task 91: hci_bdaddr_list_add+0x1a6/0x3a0 hci_cc_le_add_to_accept_list+0xab/0x140 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Freed by task 90: kfree+0x131/0x3c0 hci_bdaddr_list_clear+0xd8/0x160 hci_cc_reset+0x28a/0x370 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Take hdev->lock around both list clears. This matches the existing mutation and traversal locking convention. Fixes: a4d5504d5c39 ("Bluetooth: Clear LE white list when resetting controller") Fixes: cfdb0c2d095a ("Bluetooth: Store Resolv list size") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_aml: validate firmware segment lengthsLaxman Acharya Padhya1-2/+16
aml_download_firmware() reads two lengths from the firmware header and uses them to build pointers before checking that the header and segment data are present. A truncated or inconsistent firmware image can make the driver read past firmware->data while constructing TCI commands. Reject images shorter than the header and ensure that the ICCM and DCCM ranges fit within the loaded firmware before downloading either segment. Fixes: 37bac77e4649 ("Bluetooth: hci_uart: Add support for Amlogic HCI UART") Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btintel: Add Bluetooth SAR revision 2 supportKiran K2-1/+208
BRDS revision 2 introduces per-chain (Chain A and Chain B) TX power limits across five sub-bands (2.4G, 5.2G, 5.8/5.9G, 6G-low, 6G-high), replacing the single-chain per-modulation model of revisions 0 and 1. - Add btintel_set_sar_rev2() which sends the full Rev2 DDC sequence: 0x019e inc-power-mode enable flag (1 byte) 0x0311 2.4 GHz sub-band limits (2 bytes) 0x0312 5.2 GHz sub-band limits (2 bytes) 0x0313 5.8/5.9 GHz sub-band limits (2 bytes) 0x0314 5.8/5.9 GHz sub-band limits again (2 bytes, duplicate FW reg) 0x0315 6 GHz low sub-band limits (2 bytes) 0x0316 6 GHz high sub-band limits (2 bytes) followed by the SAR-init-complete command (0xfe25). logs from dmesg when BTSAR2 is enabled in Coreboot/BIOS: Bluetooth: hci0: BT SAR Rev2: revision=2 bt_sar_bios=1 inc_power_mode=1 Bluetooth: hci0: BT SAR Rev2 Chain A: 2g4=76 5g2=0 5g8_5g9=0 6g1=0 6g3=0 Bluetooth: hci0: BT SAR Rev2 Chain B: 2g4=102 5g2=0 5g8_5g9=0 6g1=0 6g3=0 Signed-off-by: Ravindra <ravindra@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: Add MGMT Load Connection Subrate commandLuiz Augusto von Dentz6-8/+263
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 <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: Add MGMT Shorter Connection Interval settingLuiz Augusto von Dentz3-0/+9
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 <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: Add support for Shorter Connection Interval (SCI) featureLuiz Augusto von Dentz4-2/+190
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 <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btintel_pcie: Add vendor_reset PCI sysfs for PLDRChandrashekar Devegowda3-0/+54
Add a read-write sysfs entry at /sys/bus/pci/devices/<BDF>/vendor_reset to allow userspace to trigger PLDR (Product Level Device Reset). Reading the attribute displays supported reset types. Writing integer 0 triggers PLDR. Any other input is rejected with -EINVAL and a warning log. Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_intel: drop unused assignment of acpi_device_id::driver_dataPawel Zalewski (The Capable Hub)1-2/+2
This module sets the acpi_device_id::driver_data to 0 but the field is not actually used within the module, we can just drop it from the table. While we are at it - use a named initializer for the acpi_device_id::id field and drop setting the list terminator fields explicitly as well. Signed-off-by: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: use a named initializer for acpi_device_idPawel Zalewski (The Capable Hub)3-177/+177
Use a named initializer for the acpi_device_id fields which makes the code more readable and consistent with how lists are initialized in the rest of the kernel code base. While we are at it - unify the list terminator to have a single space between the brackets without a trailing coma. Signed-off-by: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btmrvl_sdio: Do not free HCI_VENDOR_PKT frame by hci_recv_frame()Zijun Hu1-1/+1
For a HCI_VENDOR_PKT frame, hci_recv_frame() does not accept it and will kfree_skb() it directly. But btmrvl_sdio_card_to_host() is still calling hci_recv_frame() for the frame. Fix by freeing it with kfree_skb() directly. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btintel: Simplify btintel_classify_pkt_type() by hci_acl_handle()Zijun Hu1-3/+1
Simplify btintel_classify_pkt_type() by using hci_acl_handle() instead of: __u16 handle = __le16_to_cpu(hci_acl_hdr(skb)->handle); ... hci_handle(handle) ... Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btusb: Simplify btusb_recv_bulk() by hci_acl_dlen()Zijun Hu1-3/+1
Simplify btusb_recv_bulk() by using hci_acl_dlen() instead of: __le16 dlen = hci_acl_hdr(skb)->dlen; ... __le16_to_cpu(dlen) ... Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_core: Simplify hci_recv_frame() by hci_acl_handle()Zijun Hu1-2/+1
Simplify hci_recv_frame() by using hci_acl_handle() instead of: __u16 handle = __le16_to_cpu(hci_acl_hdr(skb)->handle); ... hci_handle(handle) ... Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci: Introduce hci_acl_handle() and hci_acl_dlen() helpersZijun Hu1-0/+10
Introduce both helpers for ACL packet since: both core and transport drivers extract the handle and data length from its header in several places. Both will be used later. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btusb: Add a simple static btusb_prepare_reset()Zijun Hu1-2/+9
Add btusb_prepare_reset() to do cleanup before a reset, and apply it to btusb_mtk_reset() as well. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btusb: Make btusb_recv_{event,acl}() take struct hci_dev *Zijun Hu1-6/+10
Both helpers currently take struct btusb_data *, which is private to btusb.c, as parameter type as below: int btusb_recv_event(struct btusb_data *data, struct sk_buff *skb) int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb) To allow vendor USB-transport-specific source files to share them as well, change the type to struct hci_dev *. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: coredump: Introduce and apply hci_devcd_state_name()Zijun Hu2-7/+45
Introduce hci_devcd_state_name() to describe the devcoredump state by a string name instead of a plain number, for several reasons: 1) Applying it in coredump.c makes the devcoredump state in log messages more readable than a plain number. 2) Transport drivers may need to show the devcoredump state name too. 3) In future, the universal state name could be notified to userspace via uevent, allowing a universal application (e.g. a daemon) to be developed to save the coredump, which is otherwise discarded by the device coredump core after 5 minutes (DEVCD_TIMEOUT); see nxp_coredump_notify(). Also drop a trailing space from two bt_dev_dbg() format strings while applying it in coredump.c. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: fix BT dependency for submodulesIva Kasprzaková4-4/+4
The modules rfcomm (BT_RFCOMM), bnep (BT_BNEP), hidp (BT_HIDP), and bluetooth_6lowpan (BT_6LOWPAN) are dependent on the bluetooth module (BT, tristate) only transitively through the boolean BT_BREDR for the first three and through the boolean BT_LE for the bluetooth_6lowpan. Therefore, the modules can be selected as built-in even if the BT=m. The combination of BT=m and =y for the said modules leads to the kernel build system silently ignoring those modules, without ever compiling them as built-in or as loadable modules. Add BT as a direct dependency to the Kconfig of rfcomm, bnep, hidp, and bluetooth_6lowpan. The modules set to =y when BT=m will default to =m, rather then getting silently ignored by the build system. Signed-off-by: Iva Kasprzaková <iva@yenya.net> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btrsi: Move set_bt_context after successful HCI registrationChen Changcheng1-1/+2
In rsi_hci_attach(), ops->set_bt_context() stores the newly allocated h_adapter into common->bt_adapter before hci_alloc_dev() and hci_register_dev() are called. If either of these fails, h_adapter is freed but common->bt_adapter remains a non-NULL dangling pointer. This causes a deterministically reachable use-after-free when the device operates in a BT+WiFi coexistence mode and CONFIG_RSI_COEX is enabled. The following software-only trigger paths exist: 1. SDIO driver .remove (rsi_disconnect) 2. USB driver .disconnect (rsi_disconnect) 3. SDIO driver .shutdown (rsi_shutdown) 4. Hibernation .freeze (rsi_freeze) All four paths check: if (IS_ENABLED(CONFIG_RSI_COEX) && coex_mode > 1 && bt_adapter) rsi_bt_ops.detach(bt_adapter); // use-after-free coex_mode is set during rsi_91x_init(), before rsi_hci_attach() is called, and is not cleared on attach failure. Since set_bt_context() already wrote bt_adapter before the failure, the deinit paths see a non-NULL dangling pointer and proceed to detach it. Fix this by moving set_bt_context() after hci_register_dev() succeeds. On failure paths bt_adapter stays NULL, and the deinit callers correctly skip the detach call. Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btintel_pcie: Remove unreachable break after gotoChen Changcheng1-1/+0
In the switch-case block for hardware variant detection, the default case has an unreachable 'break' statement following 'goto exit_error'. Remove the dead code. Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btusb: Realtek: Replace HCI_VENDOR_PKT usage with HCI_EV_VENDORZijun Hu1-1/+1
The macros below have different meanings even though they share the same value 0xff: HCI_VENDOR_PKT: HCI packet indicator or type HCI_EV_VENDOR: event code of a VSE This usage of HCI_VENDOR_PKT is wrongly checking an event code. Fix by using HCI_EV_VENDOR for event code. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btusb: QCA: Replace HCI_VENDOR_PKT usages with HCI_EV_VENDORZijun Hu1-2/+2
The macros below have different meanings even though they share the same value 0xff: HCI_VENDOR_PKT: HCI packet indicator or type HCI_EV_VENDOR: event code of a VSE These usages of HCI_VENDOR_PKT are wrongly checking an event code. Fix by using HCI_EV_VENDOR for event code. Also fix warning "CHECK: Unnecessary parentheses around comparison" given by checkpatch.pl. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_qca: Replace HCI_VENDOR_PKT usage with HCI_EV_VENDORZijun Hu1-2/+2
The macros below have different meanings even though they share the same value 0xff: HCI_VENDOR_PKT: HCI packet indicator or type HCI_EV_VENDOR: event code of a VSE This usage of HCI_VENDOR_PKT is wrongly checking an event code. Fix by using HCI_EV_VENDOR for event code. Also fix warning "CHECK: Unnecessary parentheses around comparison" given by checkpatch.pl. Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_ldisc: reject invalid tty write lengthsLi Qiang1-0/+6
The HCI UART write worker assumes that a tty write callback returns a value in the range from zero through the skb length. A negative value or a value larger than the skb length is passed to accounting and skb_pull, which can corrupt skb state. Treat either return value as a transmit error and discard the skb. Signed-off-by: Li Qiang <liqiang01@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: hci_bcsp: validate received packet lengthsLi Qiang1-1/+4
The BCSP transmit path reads an HCI command header when an extension packet has only been tested for a nonzero length. Its LE configuration packet handler also indexes bytes through offset seven without a length check. Validate the complete command and LE configuration packet headers before accessing their fields. Signed-off-by: Li Qiang <liqiang01@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Bluetooth: btmrvl: validate event packet lengthsLi Qiang1-0/+10
The Marvell event handlers access the HCI event header, command complete payload, and driver-specific event header before validating that the received skb contains them. A truncated event can consequently cause an out-of-bounds read. Validate each header and the command-complete payload length before dereferencing the corresponding fields. Signed-off-by: Li Qiang <liqiang01@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07Merge branch 'pm-cpuidle'Rafael J. Wysocki5-325/+583
- Avoid using deep idle states during initialization in the intel_idle driver to work around device handling issues (Rafael Wysocki) - Fix and refactor the ACPI processor driver code related to ACPI _LPI support and add ACPI _LPI support to intel_idle based on that ACPI processor driver update (Rafael Wysocki) * pm-cpuidle: intel_idle: Avoid using deep idle states during initialization intel_idle: Update documentation after adding ACPI _LPI support intel_idle: Add ACPI _LPI support intel_idle: Prepare for adding ACPI _LPI support ACPI: processor: idle: Add switch for strict _LPI processing ACPI: processor: idle: Relocate acpi_processor_extract_lpi_info() ACPI: processor: idle: Introduce acpi_processor_extract_lpi_info() ACPI: processor: idle: Introduce too_many_states() for _LPI ACPI: processor: idle: Rework flatten_lpi_states() ACPI: processor: idle: Rearrange loop in acpi_processor_get_lpi_info() ACPI: processor: idle: Drop redundant _LPI presence checks ACPI: processor: idle: Rework first-level _LPI states processing ACPI: processor: idle: Rearrange acpi_processor_get_lpi_info() ACPI: processor: idle: Introduce lpi_state_debug() ACPI: processor: idle: Split acpi_processor_evaluate_lpi() ACPI: processor: idle: Rearrange acpi_processor_evaluate_lpi() ACPI: processor: idle: Unify debug in acpi_processor_evaluate_lpi() ACPI: processor: idle: Ignore _LPI states with SYSTEMIO entry method ACPI: processor: idle: Expand _LPI package sanity checks