linux-stable.git/drivers/bluetooth, branch v6.18.40

Bluetooth: btrtl: validate firmware patch bounds

2026-07-24T14:17:18+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:16:48+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: vhci: validate devcoredump state before side effects

2026-07-24T14:16:09+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: btmtk: fix URB leak in alloc_mtk_intr_urb error path

2026-07-24T14:16:09+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:16:08+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

Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled

2026-07-18T14:53:17+00:00

commit 1b0d946d6f08bd39211385bc703a440911b41e46 upstream.

HCI_UART_SENDING bit in tx_state means write_work is pending and blocks
queueing it again.  Currently this bit is not cleared when canceling the
work in hci_uart_close(), which blocks future writes when device is
reopened later if write_work was pending.

Fix by clearing HCI_UART_SENDING when canceling the work.

Also make clearing of tx_skb safe by using disable_work_sync +
enable_work instead of just cancel_work_sync.  hci_uart_flush() purges
the proto tx queue so we can cancel the pending write_work there,
instead of doing it just in hci_uart_close().  Re-enable and possibly
requeue the work after queue flush.

Fixes: c1bb9336ae6b ("Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths")
Link: https://lore.kernel.org/linux-bluetooth/07e0a28650773abec711ee492fdb1bf5d21a6c98.camel@iki.fi/
Cc: stable@vger.kernel.org
Signed-off-by: Pauli Virtanen 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v3()

2026-07-18T14:53:17+00:00

commit badff6c3bed8923a1257a853f137d447976eec30 upstream.

During the v3 firmware download the controller sends a v3_data_req with a
32 bit offset and a 16 bit len. nxp_recv_fw_req_v3() checks only the lower
bound of the offset and then sends firmware from that offset.

  nxpdev->fw_dnld_v3_offset = offset - nxpdev->fw_v3_offset_correction;
  serdev_device_write_buf(nxpdev->serdev, nxpdev->fw->data +
                          nxpdev->fw_dnld_v3_offset, len);

Nothing checks that fw_dnld_v3_offset + len stays within nxpdev->fw->size,
so a controller that asks for an offset or length past the firmware image
makes the driver read past the end of nxpdev->fw->data and send that
memory back over UART.

nxp_recv_fw_req_v1() already bounds the same write. Add the equivalent
check to the v3 path, reject the request when it falls outside the firmware
image, and zero len on the error path so the fw_v3_prev_sent bookkeeping at
free_skb stays consistent.

Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets")
Suggested-by: Neeraj Sanjay Kale 
Reviewed-by: Neeraj Sanjay Kale 
Cc: stable@vger.kernel.org
Signed-off-by: Maoyi Xie 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()

2026-07-18T14:53:17+00:00

commit a257407e2bbbb099ed427719a50563f67fa366d8 upstream.

Every once in a while we see a hung btmtksdio_flush() task:

 INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
 __cancel_work_timer+0x3f4/0x460
 cancel_work_sync+0x1c/0x2c
 btmtksdio_flush+0x2c/0x40
 hci_dev_open_sync+0x10c4/0x2190
 [..]

It all boils down to incorrect time_is_before_jiffies() usage in
btmtksdio_txrx_work().  The btmtksdio_txrx_work() loop is expected
to be terminated if running for longer than 5*HZ.  However the
timeout check is twisted:  time_is_before_jiffies(old_jiffies + 5*HZ)
evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
timeout has occurred.  Using OR with time_is_before_jiffies(txrx_timeout)
means that:
- before the 5-second timeout: the condition is `int_status || false`,
  so it loops as long as there are pending interrupts.
- after the 5-second timeout: the condition becomes `int_status || true`,
  which is always true.

When the loop becomes infinite btmtksdio_txrx_work() loop never
terminates and never releases the SDIO host.

Fix loop termination condition to actually enforce a 5*HZ timeout.

Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Senozhatsky 
Reviewed-by: Sean Wang 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: fix wakeup source leak on probe failure

2026-07-18T14:53:11+00:00

commit 3d93e1bb0fb881fe3ef961d1120556658e9cac4d upstream.

Make sure to disable wakeup on probe failure to avoid leaking the wakeup
source.

Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support")
Cc: stable@vger.kernel.org	# 4.11
Cc: Rajat Jain 
Signed-off-by: Johan Hovold 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: fix use-after-free on marvell probe failure

2026-07-18T14:53:11+00:00

commit c5b600a3c05b1a7a110d558df935a8fc8a471c79 upstream.

Make sure to stop any TX URBs submitted during Marvell OOB wakeup
configuration on later probe failures to avoid use-after-free in the
completion callback.

This issue was reported by Sashiko while reviewing a fix for a wakeup
source leak in the btusb probe errors paths.

Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org
Fixes: a4ccc9e33d2f ("Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup")
Cc: stable@vger.kernel.org	# 4.11
Cc: Rajat Jain 
Signed-off-by: Johan Hovold 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman