kernel/git/next/linux-next.git/drivers/bluetooth/btintel.c, branch master

Bluetooth: btintel: propagate version TLV parsing errors

2026-08-31T16:48:12+00:00

btintel_read_version_tlv() ignores the parser return value, so setup continues with partially initialized version data after a malformed TLV causes parsing to stop. Return the parser error to the caller so an invalid response fails setup instead of being treated as successful. Keep this behavioral change separate from the bounds checks so it can be reverted independently if an existing controller sends malformed data. Signed-off-by: Laxman Acharya Padhya Reviewed-by: Ali Ahmet Memis Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: bound firmware ID by TLV length

2026-08-31T16:47:52+00:00

The firmware ID is treated as a NUL-terminated string even though the TLV length is its only boundary. If the value does not contain a NUL terminator, snprintf() can read beyond the received response. Limit the conversion to the advertised TLV value length. Fixes: 164c62f958f8 ("Bluetooth: btintel: Add firmware ID to firmware name") Reviewed-by: Ali Ahmet Memis Signed-off-by: Laxman Acharya Padhya Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: validate version TLV value lengths

2026-08-31T16:44:12+00:00

btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy(). Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field. Fixes: 57375beef71a ("Bluetooth: btintel: Add infrastructure to read controller information") Reviewed-by: Ali Ahmet Memis Signed-off-by: Laxman Acharya Padhya Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: parse FW memory addresses via mailbox TLV

2026-08-19T16:43:52+00:00

Implement GP1 mailbox interrupt handling to receive memory region addresses from firmware via a TLV-based protocol. When firmware sends a BUILD_SPECIFIC_RESOURCES_MAPPING mailbox message, the driver reads a TLV table from device memory containing addresses and sizes of debug memory regions (exception dump, DCCM, SDS, ECL, SMEM). This enables the driver to dynamically discover dump region locations instead of using hardcoded addresses, supporting current and future Intel BT PCIe controller variants. Replace per-device hardcoded exception memory address and size constants in btintel_pcie_read_hwexp() with the dynamically populated values from dump_info, making exception dump handling consistent with other dump regions. Key changes: - Rewrite GP1 handler to parse mailbox registers and queue TLV work - Add btintel_parse_mbox_tlv() for parsing FW-provided TLV data - Add mbox_work workqueue for deferred TLV processing - Store parsed region addresses in btintel_pcie_dump_mem_info - Add cnvi_bt field to btintel_data for HW variant identification - Rename fw_git_sha1 to fw_sha for consistency - Remove hardcoded HWEXP address/size macros and use dump_info Assisted-by: GitHub-Copilot:claude-opus-4.7 Signed-off-by: Chandrashekar Devegowda Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: Remove redundant (hdr->plen > 0) in btintel_recv_event()

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

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 Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: Fix diagnostics event detection

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

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 Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: Add Bluetooth SAR revision 2 support

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

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 Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: Simplify btintel_classify_pkt_type() by hci_acl_handle()

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

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 Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel: Validate length before parsing diagnostics TLV

2026-07-28T20:13:12+00:00

btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access. Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Support Product level reset

2026-06-11T18:24:37+00:00

When driver encounters a TOP exception, ACPI methods will be called for Product level reset since Wifi and BT share the same TOP. BT driver will first reprobe the wifi driver and then reprobe BT. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Venkat Rao Bagalkote Signed-off-by: Luiz Augusto von Dentz