kernel/linux.git/net/bluetooth/hci_sync.c, branch linux-5.17.y

bluetooth: don't use bitmaps for random flag accesses

2022-06-14T16:41:26+00:00

[ Upstream commit e1cff7002b716bd0b5f5f4afd4273c99aa8644be ] The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953fd221 ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee6425a2 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/ Reported-by: Stephen Rothwell Reported-by: Sudip Mukherjee Reviewed-by: Yury Norov Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan

2022-06-14T16:41:26+00:00

[ Upstream commit 3b42055388c30f2761a2d9cd9af2c99611dfe457 ] When suspending the passive scanning _must_ have its filter_policy set to 0x01 to use the accept list otherwise _any_ advertise report would end up waking up the system. In order to fix the filter_policy the code now checks for hdev->suspended && HCI_CONN_FLAG_REMOTE_WAKEUP first, since the MGMT_OP_SET_DEVICE_FLAGS will reject any attempt to set HCI_CONN_FLAG_REMOTE_WAKEUP when it cannot be programmed in the acceptlist, so it can return success causing the proper filter_policy to be used. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215768 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted

2022-06-09T08:25:58+00:00

[ Upstream commit 9b3628d79b46f06157affc56fdb218fdd4988321 ] This attempts to cleanup the hci_conn if it cannot be aborted as otherwise it would likely result in having the controller and host stack out of sync with respect to connection handle. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_sync: Fix queuing commands when HCI_UNREGISTER is set

2022-04-13T17:27:09+00:00

[ Upstream commit 0b94f2651f56b9e4aa5f012b0d7eb57308c773cf ] hci_cmd_sync_queue shall return an error if HCI_UNREGISTER flag has been set as that means hci_unregister_dev has been called so it will likely cause a uaf after the timeout as the hdev will be freed. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_sync: Fix compilation warning

2022-04-13T17:27:07+00:00

[ Upstream commit 89a0b8b98f49ae34886e67624208c2898e1e4d7f ] This fixes the following warning: net/bluetooth/hci_sync.c:5143:5: warning: no previous prototype for ‘hci_le_ext_create_conn_sync’ [-Wmissing-prototypes] Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_sync: fix undefined return of hci_disconnect_all_sync()

2022-04-08T11:58:15+00:00

[ Upstream commit 8cd3c55c629efd91e5f2b3e89d850575c5b90d47 ] clang static analysis reports this problem hci_sync.c:4428:2: warning: Undefined or garbage value returned to caller return err; ^~~~~~~~~~ If there are no connections this function is a noop but err is never set and a false error could be reported. Return 0 as other hci_* functions do. Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Signed-off-by: Tom Rix Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin

Bluetooth: hci_sync: Add a new quirk to skip HCI_FLT_CLEAR_ALL

2022-03-28T08:03:20+00:00

commit 0eaecfb2e4814d51ab172df3823e35d7c488b6d2 upstream. Some controllers have problems with being sent a command to clear all filtering. While the HCI code does not unconditionally send a clear-all anymore at BR/EDR setup (after the state machine refactor), there might be more ways of hitting these codepaths in the future as the kernel develops. Cc: stable@vger.kernel.org Cc: Hans de Goede Signed-off-by: Ismael Ferreras Morezuelas Reviewed-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work

2022-03-03T12:30:03+00:00

hci_cmd_sync_queue can be called multiple times, each adding a hci_cmd_sync_work_entry, before hci_cmd_sync_work is run so this makes sure they are all dequeued properly otherwise it creates a backlog of entries that are never run. Link: https://lore.kernel.org/all/CAJCQCtSeUtHCgsHXLGrSTWKmyjaQDbDNpP4rb0i+RE+L2FTXSA@mail.gmail.com/T/ Fixes: 6a98e3836fa20 ("Bluetooth: Add helper for serialized HCI command execution") Tested-by: Chris Clayton Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: hci_sync: Fix not using conn_timeout

2022-02-24T20:34:28+00:00

When using hci_le_create_conn_sync it shall wait for the conn_timeout since the connection complete may take longer than just 2 seconds. Also fix the masking of HCI_EV_LE_ENHANCED_CONN_COMPLETE and HCI_EV_LE_CONN_COMPLETE so they are never both set so we can predict which one the controller will use in case of HCI_OP_LE_CREATE_CONN. Fixes: 6cd29ec6ae5e3 ("Bluetooth: hci_sync: Wait for proper events when connecting LE") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: hci_sync: Fix hci_update_accept_list_sync

2022-02-24T20:07:01+00:00

hci_update_accept_list_sync is returning the filter based on the error but that gets overwritten by hci_le_set_addr_resolution_enable_sync return instead of using the actual result of the likes of hci_le_add_accept_list_sync which was intended. Fixes: ad383c2c65a5b ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann