kernel/linux.git/drivers/bluetooth, branch v4.14.263

Bluetooth: bfusb: fix division by zero in send path

2022-01-27T08:00:46+00:00

commit b5e6fa7a12572c82f1e7f2f51fbb02a322291291 upstream. Add the missing bulk-out endpoint sanity check to probe() to avoid division by zero in bfusb_send_frame() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: Apply QCA Rome patches for some ATH3012 models

2022-01-11T12:57:34+00:00

commit 803cdb8ce584198cd45825822910cac7de6378cb upstream. In commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174") we tried to address the non-working Atheros BT devices by changing the quirk from BTUSB_ATH3012 to BTUSB_QCA_ROME. This made such devices working while it turned out to break other existing chips with the very same USB ID, hence it was reverted afterwards. This is another attempt to tackle the issue. The essential point to use BTUSB_QCA_ROME is to apply the btusb_setup_qca() and do RAM- patching. And the previous attempt failed because btusb_setup_qca() returns -ENODEV if the ROM version doesn't match with the expected ones. For some devices that have already the "correct" ROM versions, we may just skip the setup procedure and continue the rest. So, the first fix we'll need is to add a check of the ROM version in the function to skip the setup if the ROM version looks already sane, so that it can be applied for all ath devices. However, the world is a bit more complex than that simple solution. Since BTUSB_ATH3012 quirk checks the bcdDevice and bails out when it's 0x0001 at the beginning of probing, so the device probe always aborts here. In this patch, we add another check of ROM version again, and if the device needs patching, the probe continues. For that, a slight refactoring of btusb_qca_send_vendor_req() was required so that the probe function can pass usb_device pointer directly before allocating hci_dev stuff. Fixes: commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174") Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 Tested-by: Ivan Levshin Signed-off-by: Takashi Iwai Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: fix bt fiwmare downloading failure issue for qca btsoc.

2021-07-20T14:17:45+00:00

[ Upstream commit 4f00bfb372674d586c4a261bfc595cbce101fbb6 ] This is btsoc timing issue, after host start to downloading bt firmware, ep2 need time to switch from function acl to function dfu, so host add 20ms delay as workaround. Signed-off-by: Tim Jiang Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function

2021-03-03T17:22:37+00:00

[ Upstream commit 9a39a927be01d89e53f04304ab99a8761e08910d ] Some resource should be released in the error handling path of the probe function, as already done in the remove function. The remove function was fixed in commit 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Christophe JAILLET Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_uart: Cancel init work before unregistering

2020-10-29T08:07:03+00:00

[ Upstream commit 3b799254cf6f481460719023d7a18f46651e5e7f ] If hci_uart_tty_close() or hci_uart_unregister_device() is called while hu->init_ready is scheduled, hci_register_dev() could be called after the hci_uart is torn down. Avoid this by ensuring the work is complete or canceled before checking the HCI_UART_REGISTERED flag. Fixes: 9f2aee848fe6 ("Bluetooth: Add delayed init sequence support for UART controllers") Signed-off-by: Samuel Holland Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_serdev: Only unregister device if it was registered

2020-08-21T07:48:11+00:00

[ Upstream commit 202798db9570104728dce8bb57dfeed47ce764bc ] We should not call hci_unregister_dev if the device was not successfully registered. Fixes: c34dc3bfa7642fd ("Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()") Signed-off-by: Nicolas Boichat Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: btusb: fix PM leak in error case of setup

2020-01-09T09:17:57+00:00

commit 3d44a6fd0775e6215e836423e27f8eedf8c871ea upstream. If setup() fails a reference for runtime PM has already been taken. Proper use of the error handling in btusb_open()is needed. You cannot just return. Fixes: ace31982585a3 ("Bluetooth: btusb: Add setup callback for chip init on USB") Signed-off-by: Oliver Neukum Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_bcm: Handle specific unknown packets after firmware loading

2019-12-05T14:37:37+00:00

[ Upstream commit 22bba80500fdf624a7cfbb65fdfa97a038ae224d ] The Broadcom controller on aries S5PV210 boards sends out a couple of unknown packets after the firmware is loaded. This will cause logging of errors such as: Bluetooth: hci0: Frame reassembly failed (-84) This is probably also the case with other boards, as there are related Android userspace patches for custom ROMs such as https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/142721/ Since this appears to be intended behaviour, treated them as diagnostic packets. Note that this is another variant of commit 01d5e44ace8a ("Bluetooth: hci_bcm: Handle empty packet after firmware loading") Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: Fix invalid-free in bcsp_close()

2019-12-01T08:14:15+00:00

commit cf94da6f502d8caecabd56b194541c873c8a7a3c upstream. Syzbot reported an invalid-free that I introduced fixing a memleak. bcsp_recv() also frees bcsp->rx_skb but never nullifies its value. Nullify bcsp->rx_skb every time it is freed. Signed-off-by: Tomas Bortoli Reported-by: syzbot+a0d209a4676664613e76@syzkaller.appspotmail.com Signed-off-by: Marcel Holtmann Cc: Alexander Potapenko Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_serdev: clear HCI_UART_PROTO_READY to avoid closing proto races

2019-11-20T17:00:46+00:00

[ Upstream commit 7cf7846d27bfc9731e449857db3eec5e0e9701ba ] Clearing HCI_UART_PROTO_READY will avoid usage of proto function pointers before running the proto close function pointer. There is chance of kernel crash, due to usage of non proto close function pointers after proto close. Signed-off-by: Balakrishna Godavarthi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin