linux-stable.git/drivers/bluetooth, branch v4.4.301

Bluetooth: bfusb: fix division by zero in send path

2022-01-27T07:46:12+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:37:11+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:22:39+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: btmrvl: fix hung task warning dump

2020-05-10T08:25:51+00:00

commit 86f7ac77d4035e22ec7e58dcdb96327e2ecc3a9b upstream.

It's been observed that when bluetooth driver fails to
activate the firmware, below hung task warning dump is
displayed after 120 seconds.

[   36.461022] Bluetooth: vendor=0x2df, device=0x912e, class=255, fn=2
[   56.512128] Bluetooth: FW failed to be active in time!
[   56.517264] Bluetooth: Downloading firmware failed!
[  240.252176] INFO: task kworker/3:2:129 blocked for more than 120 seconds.
[  240.258931]       Not tainted 3.18.0 #254
[  240.262972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.270751] kworker/3:2     D ffffffc000205760     0   129      2 0x00000000
[  240.277825] Workqueue: events request_firmware_work_func
[  240.283134] Call trace:
[  240.285581] [] __switch_to+0x80/0x8c
[  240.290693] [] __schedule+0x540/0x7b8
[  240.295921] [] schedule+0x78/0x84
[  240.300764] [] __mmc_claim_host+0xe8/0x1c8
[  240.306395] [] sdio_claim_host+0x74/0x84
[  240.311840] [] 0xffffffbffc163d08
[  240.316685] [] 0xffffffbffc165104
[  240.321524] [] mwifiex_dnld_fw+0x98/0x110 [mwifiex]
[  240.327918] [] mwifiex_remove_card+0x2c4/0x5fc [mwifiex]
[  240.334741] [] request_firmware_work_func+0x44/0x80
[  240.341127] [] process_one_work+0x2ec/0x50c
[  240.346831] [] worker_thread+0x350/0x470
[  240.352272] [] kthread+0xf0/0xfc
[  240.357019] 2 locks held by kworker/3:2/129:
[  240.361248]  #0:  ("events"){.+.+.+}, at: [] process_one_work+0x1f8/0x50c
[  240.369562]  #1:  ((&fw_work->work)){+.+.+.}, at: [] process_one_work+0x1f8/0x50c
[  240.378589]   task                        PC stack   pid father
[  240.384501] kworker/1:1     D ffffffc000205760     0    40      2 0x00000000
[  240.391524] Workqueue: events mtk_atomic_work
[  240.395884] Call trace:
[  240.398317] [] __switch_to+0x80/0x8c
[  240.403448] [] lock_acquire+0x128/0x164
[  240.408821] kworker/3:2     D ffffffc000205760     0   129      2 0x00000000
[  240.415867] Workqueue: events request_firmware_work_func
[  240.421138] Call trace:
[  240.423589] [] __switch_to+0x80/0x8c
[  240.428688] [] __schedule+0x540/0x7b8
[  240.433886] [] schedule+0x78/0x84
[  240.438732] [] __mmc_claim_host+0xe8/0x1c8
[  240.444361] [] sdio_claim_host+0x74/0x84
[  240.449801] [] 0xffffffbffc163d08
[  240.454649] [] 0xffffffbffc165104
[  240.459486] [] mwifiex_dnld_fw+0x98/0x110 [mwifiex]
[  240.465882] [] mwifiex_remove_card+0x2c4/0x5fc [mwifiex]
[  240.472705] [] request_firmware_work_func+0x44/0x80
[  240.479090] [] process_one_work+0x2ec/0x50c
[  240.484794] [] worker_thread+0x350/0x470
[  240.490231] [] kthread+0xf0/0xfc

This patch adds missing sdio_release_host() call so that wlan driver
thread can claim sdio host.

Fixes: 4863e4cc31d647e1 ("Bluetooth: btmrvl: release sdio bus after firmware is up")
Signed-off-by: Chin-Ran Lo 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

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

2020-01-12T10:22:43+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: Fix invalid-free in bcsp_close()

2019-11-28T17:26:12+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_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()

2019-11-25T14:54:18+00:00

commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.

task A:                                task B:
hci_uart_set_proto                     flush_to_ldisc
 - p->open(hu) -> h5_open  //alloc h5  - receive_buf
 - set_bit HCI_UART_PROTO_READY         - tty_port_default_receive_buf
 - hci_uart_register_dev                 - tty_ldisc_receive_buf
                                          - hci_uart_tty_receive
				           - test_bit HCI_UART_PROTO_READY
				            - h5_recv
 - clear_bit HCI_UART_PROTO_READY             while() {
 - p->open(hu) -> h5_close //free h5
				              - h5_rx_3wire_hdr
				               - h5_reset()  //use-after-free
                                              }

It could use ioctl to set hci uart proto, but there is
a use-after-free issue when hci_uart_register_dev() fail in
hci_uart_set_proto(), see stack above, fix this by setting
HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
return success.

Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
Signed-off-by: Kefeng Wang 
Reviewed-by: Jeremy Cline 
Signed-off-by: Marcel Holtmann 
Cc: Ralph Siemsen 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data

2019-11-25T14:54:18+00:00

commit 84cb3df02aea4b00405521e67c4c67c2d525c364 upstream.

HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we
receive data from tty layer during this procedure, proto pointer may
not be assigned yet, leading to null pointer dereference in rx method
hci_uart_tty_receive.

This patch fixes this issue by introducing HCI_UART_PROTO_READY flag in
order to avoid any proto operation before proto opening and assignment.

Signed-off-by: Loic Poulain 
Signed-off-by: Marcel Holtmann 
Cc: Ralph Siemsen 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devices

2019-10-05T10:27:40+00:00

[ Upstream commit 6d0762b19c5963ff9e178e8af3626532ee04d93d ]

The ASUS X412FA laptop contains a Realtek RTL8822CE device with an
associated BT chip using a USB ID of 04ca:4005. This ID is added to the
driver.

The /sys/kernel/debug/usb/devices portion for this device is:

T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=4005 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204707
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: btqca: Add a short delay before downloading the NVM

2019-09-10T09:29:46+00:00

[ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ]

On WCN3990 downloading the NVM sometimes fails with a "TLV response
size mismatch" error:

[  174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
[  174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch

It seems the controller needs a short time after downloading the
firmware before it is ready for the NVM. A delay as short as 1 ms
seems sufficient, make it 10 ms just in case. No event is received
during the delay, hence we don't just silently drop an extra event.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin