linux-stable.git/drivers/bluetooth, branch v7.1.5

Bluetooth: btrtl: validate firmware patch bounds

2026-07-24T14:21:22+00:00

commit 609c5b04a28dc1b0f3af6a7bc93055135b2d2059 upstream.

rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the
firmware version. A malformed firmware patch shorter than the version field
can make this subtraction underflow and turn the copy into an oversized
read and write during Bluetooth setup.

The existing patch_offset + patch_length check can also wrap on 32-bit
architectures. Validate the patch length and range without arithmetic
overflow before allocating or copying the patch.

Fixes: db33c77dddc2 ("Bluetooth: btrtl: Create separate module for Realtek BT driver")
Cc: stable@vger.kernel.org
Signed-off-by: Laxman Acharya Padhya 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()

2026-07-24T14:20:43+00:00

[ Upstream commit dd068ef044128db655f48323a4acfd5907e04903 ]

bpa10x_setup() sends the vendor command 0xfc0e and passes the response
to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at
skb->data + 1, without checking the length:

	bt_dev_info(hdev, "%s", (char *)(skb->data + 1));
	hci_set_fw_info(hdev, "%s", skb->data + 1);

A device that returns a one-byte response (status only) leaves
skb->data + 1 past the end of the data, and the %s walk reads adjacent
slab memory until it meets a NUL. The same happens when the payload is
not NUL-terminated within skb->len. The out-of-bounds bytes end up in
the kernel log and the firmware-info debugfs file.

Print the revision string with a bounded "%.*s" limited to skb->len - 1
instead. This keeps the string readable for well-behaved devices while
never reading past the received data, and does not fail setup, so a
device returning a short or unterminated response keeps working.

Fixes: ddd68ec8f484 ("Bluetooth: bpa10x: Read revision information in setup stage")
Reported-by: Xiang Mei 
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi 
Reported-by: Xiang Mei 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin

Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()

2026-07-24T14:20:43+00:00

[ Upstream commit 9c36951474d8e1127f4946f39cb874a200f34e9f ]

The FLR branch in btintel_pcie_reset_work() open-coded the entire
re-init sequence: btintel_pcie_release_hdev() (hci_unregister_dev +
hci_free_dev), pci_try_reset_function(), enable_interrupts /
config_msix / enable_bt / reset_ia / start_rx, then
btintel_pcie_setup_hdev() (hci_alloc_dev_priv + hci_register_dev).
Every probe() init step had to be kept in sync with this second
copy in the reset path, and any failure mid-sequence left state to
unwind by hand.

The PLDR path already delegates teardown and re-init to the PCI
core via device_reprobe(): .remove() destroys data through devres
and unregisters hdev, then .probe() rebuilds everything from
scratch. Apply the same model to FLR.

Introduce btintel_pcie_perform_flr() mirroring perform_pldr(). It
runs pci_try_reset_function() (required to avoid the device_lock
ABBA against btintel_pcie_remove(), which calls
disable_work_sync(&reset_work) while holding device_lock) followed
by device_reprobe(). On success, data is destroyed and a fresh
probe re-INIT_WORKs coredump_work with disable count 0, so
enable_work() must not be called; on failure, data is still alive
and the caller balances the earlier disable_work_sync(). The
contract is documented on the helper and reiterated at the
reset_work() call site.

reset_work() shrinks to interrupt/worker drain, dispatch on
reset_type, and the single asymmetry between the two paths. The
out_enable label, the manual unregister/register pair, and the
forward declaration of btintel_pcie_setup_hdev() are dropped.

No intended functional change; FLR and PLDR now share one
teardown contract.

Fixes: 256ab9520d15 ("Bluetooth: btintel_pcie: Support Function level reset")
Assisted-by: GitHub-Copilot:claude-4.7-opus
Signed-off-by: Kiran K 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin

Bluetooth: btintel_pcie: Separate coredump work from RX work

2026-07-24T14:20:43+00:00

[ Upstream commit f70f7f2512c6b9113dc78f6a25361166afd1412e ]

Sharing a single workqueue between coredump processing and RX
delays evacuation of RX events while a coredump is in progress.
The firmware's RX buffers can overflow during that window, leading
to dropped events. The issue was observed in HID use cases where
HID reports arrive in bursts and quickly fill the RX path while a
coredump is being collected.

Move coredump processing to a dedicated ordered coredump_workqueue
with its own coredump_work, so coredumps run independently of RX.
All four coredump trigger sources (FW assert, HW exception, user
sysfs trigger, and resume-error detection) are switched to this new
workqueue. Ordering serialises concurrent triggers without blocking
RX.

Signed-off-by: Ravindra 
Signed-off-by: Kiran K 
Signed-off-by: Luiz Augusto von Dentz 
Stable-dep-of: 9c36951474d8 ("Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()")
Signed-off-by: Sasha Levin

Bluetooth: btintel_pcie: Add support for smart trigger dump

2026-07-24T14:20:43+00:00

[ Upstream commit 975a70ff0aec8a2be0d633113f781b301db4a816 ]

Based on the debug configuration, firmware can raise MSI-X interrupt with
firmware trigger cause bit set on specific events like Disconnection,
Connection Timeout, Page Timeout etc.

Upon receiving an MSI-X interrupt with the firmware trigger cause bit
set, the driver performs the following actions:

1. Reads Device Memory: Retrieves data from the device memory,
   constructs an HCI diagnostic event, and sends it to the monitor. This
   event includes details about the trigger, such as connection timeout or
   page timeout.

2. Dumps Device Coredump: Generates a coredump containing firmware
   traces for further analysis.

The coredump can be retrieved using:

  $ cat /sys/class/devcoredump/devcd*/data > /tmp/btintel_coredump.bin

HCI traces:
= Vendor Diagnostic (len 12)
        a5 a5 a5 a5 01 03 00 23 00 01 00 00

Signed-off-by: Kiran K 
Signed-off-by: Luiz Augusto von Dentz 
Stable-dep-of: 9c36951474d8 ("Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()")
Signed-off-by: Sasha Levin

Bluetooth: btintel_pcie: Support Product level reset

2026-07-24T14:20:43+00:00

[ Upstream commit 2d00975c841fa2e52921353392ce9780843bfee7 ]

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 
Stable-dep-of: 9c36951474d8 ("Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()")
Signed-off-by: Sasha Levin

Bluetooth: vhci: validate devcoredump state before side effects

2026-07-24T14:19:47+00:00

[ Upstream commit 88c2404a3c59c3126453919388dbd5ed98ed01bd ]

The VHCI force_devcoredump debugfs hook accepts a small test record from
userspace. It validates the requested terminal state only after
registering, initializing and appending a Bluetooth devcoredump.

As a result, an invalid state returns -EINVAL but still leaves queued
devcoredump work behind. With a non-zero timeout field, the rejected
write can still emit a devcoredump after the timeout expires.

Reject unsupported states before allocating the skb or changing the HCI
devcoredump state machine.

Fixes: ab4e4380d4e1 ("Bluetooth: Add vhci devcoredump support")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin

Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant

2026-07-24T14:19:47+00:00

[ Upstream commit e43b33bf8d671c50a45fe5f487819927595bbd50 ]

Load the IOSF DBGC base address based on the controller hardware
variant when reading DRAM buffers during a trace dump. Scorpius
Peak family controllers (SCP/SCP2/SCP2F) use a different DBGC base
address (0xf0d5d500) than Blazar family controllers (BZRI/BZRIW,
0xf3800300).

Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump")
Signed-off-by: Sai Teja Aluvala 
Signed-off-by: Kiran K 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin

Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path

2026-07-24T14:19:47+00:00

[ Upstream commit f396f4005180928cd9e15e352a6512865d3bc908 ]

When btmtk_isopkt_pad() fails, the previously allocated URB is not freed,
leaking the urb structure. Add usb_free_urb() before returning the error.

Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions")
Signed-off-by: Zhao Dongdong 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin

Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for non-serdev device

2026-07-24T14:19:47+00:00

[ Upstream commit 6b8cbcf08de0db62254d1981f83db0f94681ccd9 ]

hu->serdev is NULL for hci_uart attached via non-serdev paths, but
qca_dmp_hdr() unconditionally dereferences hu->serdev->dev.driver->name,
causing a NULL pointer dereference.

Fix by guarding the dereference with a NULL check and falling back to
"hci_ldisc_qca" for the non-serdev case.

Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
Signed-off-by: Zijun Hu 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin