linux-stable.git/drivers/bluetooth, branch linux-5.0.y

Bluetooth: btbcm: Add default address for BCM43341B

2019-05-31T13:45:01+00:00

[ Upstream commit 5035726128cd2e3813ee44deedb9898509edb232 ]

The BCM43341B has the default MAC address 43:34:1B:00:1F:AC if none
is given. This address was found when enabling Bluetooth on multiple
Intel Edison modules. It also contains the sequence 43341B, the name
the chip identifies itself as. Using the same BD_ADDR is problematic
when having multiple Intel Edison modules in each others range.
The default address also has the LAA (locally administered address)
bit set which prevents a BNEP device from being created, needed for
BT tethering.

Add this to the list of black listed default MAC addresses and let
the user configure a valid one using f.i.
`btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx`

Suggested-by: Andy Shevchenko 
Signed-off-by: Ferry Toth 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Give enough time to ROME controller to bootup.

2019-05-31T13:45:01+00:00

[ Upstream commit 7f09d5a6c33be66a5ca19bf9dd1c2d90c5dfcf0d ]

This patch enables enough time to ROME controller to bootup
after we bring the enable pin out of reset.

Fixes: 05ba533c5c11 ("Bluetooth: hci_qca: Add serdev support").
Signed-off-by: Balakrishna Godavarthi 
Reviewed-by: Rocky Liao 
Tested-by: Rocky Liao 
Tested-by: Claire Chang 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_bcm: Fix empty regulator supplies for Intel Macs

2019-05-10T16:36:13+00:00

commit 62611abc8f37d00e3b0cff0eb2d72fa92b05fd27 upstream.

The code path for Macs goes through bcm_apple_get_resources(), which
skips over the code that sets up the regulator supplies. As a result,
the call to regulator_bulk_enable() / regulator_bulk_disable() results
in a NULL pointer dereference.

This was reported on the kernel.org Bugzilla, bug 202963.

Unbreak Broadcom Bluetooth support on Intel Macs by checking if the
supplies were set up before enabling or disabling them.

The same does not need to be done for the clocks, as the common clock
framework API checks for NULL pointers.

Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies")
Cc:  # 5.0.x
Signed-off-by: Chen-Yu Tsai 
Tested-by: Imre Kaloz 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: mediatek: fix up an error path to restore bdev->tx_state

2019-05-08T05:22:55+00:00

commit 77f328dbc6cf42f22c691a164958a5452142a542 upstream.

Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT
when there is an error on waiting for the corresponding event.

Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: Sean Wang 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: request wake pin with NOAUTOEN

2019-05-08T05:22:55+00:00

commit 771acc7e4a6e5dba779cb1a7fd851a164bc81033 upstream.

Badly-designed systems might have (for example) active-high wake pins
that default to high (e.g., because of external pull ups) until they
have an active firmware which starts driving it low.  This can cause an
interrupt storm in the time between request_irq() and disable_irq().

We don't support shared interrupts here, so let's just pre-configure the
interrupt to avoid auto-enabling it.

Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support")
Fixes: 5364a0b4f4be ("arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node")
Signed-off-by: Brian Norris 
Reviewed-by: Matthias Kaehlcke 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()

2019-03-27T05:17:58+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 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_ldisc: Initialize hci_dev before open()

2019-03-27T05:17:57+00:00

commit 32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream.

The hci_dev struct hdev is referenced in work queues and timers started
by open() in some protocols. This creates a race between the
initialization function and the work or timer which can result hdev
being dereferenced while it is still null.

The syzbot report contains a reliable reproducer which causes a null
pointer dereference of hdev in hci_uart_write_work() by making the
memory allocation for hdev fail.

To fix this, ensure hdev is valid from before calling a protocol's
open() until after calling a protocol's close().

Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
Signed-off-by: Jeremy Cline 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()

2019-03-27T05:17:57+00:00

commit 1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream.

h4_recv_buf() callers store the return value to socket buffer and
recursively pass the buffer to h4_recv_buf() without protection. So,
ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
before setting the socket buffer to NULL from previous error. Check if
skb is ERR_PTR in h4_recv_buf().

Reported-by: syzbot+017a32f149406df32703@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btrtl: Restore old logic to assume firmware is already loaded

2019-03-10T06:09:01+00:00

commit 00df214b1faae520880cc5c57e206f21239ef741 upstream.

Realtek bluetooth may not work after reboot:
[   12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e, hci rev 826c, hci ver 0008

This is a regression introduced by commit 26503ad25de8 ("Bluetooth:
btrtl: split the device initialization into smaller parts"). The new
logic errors out early when no matching IC info can be found, in this
case it means the firmware is already loaded.

So let's assume the firmware is already loaded when we can't find
matching IC info, like the old logic did.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201921
Fixes: 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts")
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_bcm: Handle specific unknown packets after firmware loading

2018-12-19T12:43:42+00:00

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