JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 989fa5171f005ecf63440057218d8aeb1795287d
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Tue Oct 22 11:09:13 2024 -0400
Bluetooth: hci_core: Disable works on hci_unregister_dev
This make use of disable_work_* on hci_unregister_dev since the hci_dev is
about to be freed new submissions are not disarable.
Fixes: 0d151a103775 ("Bluetooth: hci_core: cancel all works upon hci_unregister_dev()")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit cfbfeee61582e638770a1a10deef866c9adb38f5
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Aug 16 12:05:00 2023 -0700
Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL
This ignores errors from HCI_OP_REMOTE_NAME_REQ_CANCEL since it
shouldn't interfere with the stopping of discovery and in certain
conditions it seems to be failing.
Link: https://github.com/bluez/bluez/issues/575
Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit c898f6d7b093bd71e66569cd6797c87d4056f44b
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Aug 26 15:47:30 2024 -0400
Bluetooth: hci_sync: Introduce hci_cmd_sync_run/hci_cmd_sync_run_once
This introduces hci_cmd_sync_run/hci_cmd_sync_run_once which acts like
hci_cmd_sync_queue/hci_cmd_sync_queue_once but runs immediately when
already on hdev->cmd_sync_work context.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit b5431dc2803ac159d6d4645ae237d15c3cb252db
Author: Anton Khirnov <anton@khirnov.net>
Date: Mon Jul 29 21:58:10 2024 +0200
Bluetooth: hci_sync: avoid dup filtering when passive scanning with adv monitor
This restores behaviour (including the comment) from now-removed
hci_request.c, and also matches existing code for active scanning.
Without this, the duplicates filter is always active when passive
scanning, which makes it impossible to work with devices that send
nontrivial dynamic data in their advertisement reports.
Fixes: abfeea476c68 ("Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY")
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 96b82af36efaa1787946e021aa3dc5410c05beeb
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 15 10:40:03 2024 -0400
Bluetooth: hci_sync: Fix suspending with wrong filter policy
When suspending the scan filter policy cannot be 0x00 (no acceptlist)
since that means the host has to process every advertisement report
waking up the system, so this attempts to check if hdev is marked as
suspended and if the resulting filter policy would be 0x00 (no
acceptlist) then skip passive scanning if thre no devices in the
acceptlist otherwise reset the filter policy to 0x01 so the acceptlist
is used since the devices programmed there can still wakeup be system.
Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit f2d89775358606c7ab6b6b6c4a02fe1e8cd270b1
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 1 16:52:57 2024 -0400
Bluetooth: hci_sync: Remove remaining dependencies of hci_request
This removes the dependencies of hci_req_init and hci_request_cancel_all
from hci_sync.c.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 8bedf130c265384fb136b19b20504239240c51bf
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 1 16:50:30 2024 -0400
Bluetooth: hci_sync: Move handling of interleave_scan
This moves handling of interleave_scan work to hci_sync.c since
hci_request.c is deprecated.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 176cbeceb5c5a740216a6be3e751e76aaddf94b9
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 1 16:13:56 2024 -0400
Bluetooth: hci_core: Don't use hci_prepare_cmd
This replaces the instance of hci_prepare_cmd with hci_cmd_sync_alloc
since the former is part of hci_request.c which is considered
deprecated.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 92048ab2e2e6cc90ad1cc9f55deb5cec4d731793
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 1 16:00:08 2024 -0400
Bluetooth: hci_core: Remove usage of hci_req_sync
hci_request functions are considered deprecated so this replaces the
usage of hci_req_sync with hci_inquiry_sync.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 3ba74b2f288bbc17c0c2a58ab219e1df19f80153
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date: Fri Jun 21 16:01:55 2024 +0300
Bluetooth: hci_core: cleanup struct hci_dev
Remove unused and set but otherwise unused 'discovery_old_state'
and 'sco_last_tx' members of 'struct hci_dev'. The first one is
a leftover after commit 182ee45da083 ("Bluetooth: hci_sync: Rework
hci_suspend_notifier"); the second one is originated from ancient
2.4.19 and I was unable to find any actual use since that.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 0ece498c27d8cd2fdad6f49a6abc34b8badd8fbc
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri May 10 10:36:45 2024 -0400
Bluetooth: MGMT: Make MGMT_OP_LOAD_CONN_PARAM update existing connection
This makes MGMT_OP_LOAD_CONN_PARAM update existing connection by
dectecting the request is just for one connection, parameters already
exists and there is a connection.
Since this is a new behavior the revision is also updated to enable
userspace to detect it.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 86fbd9f63a6b42b8f158361334f5a25762aea358
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed May 15 10:32:01 2024 -0400
Bluetooth: hci_sync: Fix not using correct handle
When setting up an advertisement the code shall always attempt to use
the handle set by the instance since it may not be equal to the instance
ID.
Fixes: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit e77f43d531af41e9ce299eab10dcae8fa5dbc293
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon May 13 16:07:55 2024 -0400
Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1
If hdev->le_num_of_adv_sets is set to 1 it means that only handle 0x00
can be used, but since the MGMT interface instances start from 1
(instance 0 means all instances in case of MGMT_OP_REMOVE_ADVERTISING)
the code needs to map the instance to handle otherwise users will not be
able to advertise as instance 1 would attempt to use handle 0x01.
Fixes: 1d0fac2c38 ("Bluetooth: Use controller sets when available")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 73b2652cbbb9993fe6a4340e6f5a2870d7ce6fb4
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date: Wed May 1 11:50:02 2024 -0600
Bluetooth: hci_sync: Use cmd->num_cis instead of magic number
At the moment of the check, `cmd->num_cis` holds the value of 0x1f,
which is the max number of elements in the `cmd->cis[]` array at
declaration, which is 0x1f.
So, avoid using 0x1f directly, and instead use `cmd->num_cis`. Similarly
to this other patch[1].
Link: https://lore.kernel.org/linux-hardening/ZivaHUQyDDK9fXEk@neat/ [1]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit c4585edf708edb5277a3cc4b8581ccb833f3307d
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date: Fri Apr 26 16:52:46 2024 -0600
Bluetooth: hci_conn, hci_sync: Use __counted_by() to avoid -Wfamnae warnings
Prepare for the coming implementation by GCC and Clang of the
__counted_by attribute. Flexible array members annotated with
__counted_by can have their accesses bounds-checked at run-time
via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE
(for strcpy/memcpy-family functions).
Also, -Wflex-array-member-not-at-end is coming in GCC-14, and we are
getting ready to enable it globally.
So, use the `DEFINE_FLEX()` helper for multiple on-stack definitions
of a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
Notice that, due to the use of `__counted_by()` in `struct
hci_cp_le_create_cis`, the for loop in function `hci_cs_le_create_cis()`
had to be modified. Once the index `i`, through which `cp->cis[i]` is
accessed, falls in the interval [0, cp->num_cis), `cp->num_cis` cannot
be decremented all the way down to zero while accessing `cp->cis[]`:
net/bluetooth/hci_event.c:4310:
4310 for (i = 0; cp->num_cis; cp->num_cis--, i++) {
...
4314 handle = __le16_to_cpu(cp->cis[i].cis_handle);
otherwise, only half (one iteration before `cp->num_cis == i`) or half
plus one (one iteration before `cp->num_cis < i`) of the items in the
array will be accessed before running into an out-of-bounds issue. So,
in order to avoid this, set `cp->num_cis` to zero just after the for
loop.
Also, make use of `aux_num_cis` variable to update `cmd->num_cis` after
a `list_for_each_entry_rcu()` loop.
With these changes, fix the following warnings:
net/bluetooth/hci_sync.c:1239:56: warning: structure containing a flexible
array member is not at the end of another structure
[-Wflex-array-member-not-at-end]
net/bluetooth/hci_sync.c:1415:51: warning: structure containing a flexible
array member is not at the end of another structure
[-Wflex-array-member-not-at-end]
net/bluetooth/hci_sync.c:1731:51: warning: structure containing a flexible
array member is not at the end of another structure
[-Wflex-array-member-not-at-end]
net/bluetooth/hci_sync.c:6497:45: warning: structure containing a flexible
array member is not at the end of another structure
[-Wflex-array-member-not-at-end]
Link: https://github.com/KSPP/linux/issues/202
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 2e7ed5f5e69b6fe93dd3c6b651d041e0a7a456d1
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Apr 5 16:40:33 2024 -0400
Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync
The extended advertising reports do report the PHYs so this store then
in hci_conn so it can be later used in hci_le_ext_create_conn_sync to
narrow the PHYs to be scanned since the controller will also perform a
scan having a smaller set of PHYs shall reduce the time it takes to
find and connect peers.
Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 53cb4197e63ab2363aa28c3029061e4d516e7626
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Thu Mar 28 15:58:10 2024 -0400
Bluetooth: hci_sync: Fix using the same interval and window for Coded PHY
Coded PHY recommended intervals are 3 time bigger than the 1M PHY so
this aligns with that by multiplying by 3 the values given to 1M PHY
since the code already used recommended values for that.
Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 6946b9c99bde45f3ba74e00a7af9a3458cc24bea
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Tue Mar 26 12:43:17 2024 -0400
Bluetooth: hci_sync: Fix not checking error on hci_cmd_sync_cancel_sync
hci_cmd_sync_cancel_sync shall check the error passed to it since it
will be propagated using req_result which is __u32 it needs to be
properly set to a positive value if it was passed as negative othertise
IS_ERR will not trigger as -(errno) would be converted to a positive
value.
Fixes: 63298d6e752f ("Bluetooth: hci_core: Cancel request on command timeout")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Reported-and-tested-by: Thorsten Leemhuis <linux@leemhuis.info>
Closes: https://lore.kernel.org/all/08275279-7462-4f4a-a0ee-8aa015f829bc@leemhuis.info/
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 39646f29b100566451d37abc4cc8cdd583756dfe
Author: Johan Hovold <johan+linaro@kernel.org>
Date: Wed Mar 20 08:55:53 2024 +0100
Bluetooth: add quirk for broken address properties
Some Bluetooth controllers lack persistent storage for the device
address and instead one can be provided by the boot firmware using the
'local-bd-address' devicetree property.
The Bluetooth devicetree bindings clearly states that the address should
be specified in little-endian order, but due to a long-standing bug in
the Qualcomm driver which reversed the address some boot firmware has
been providing the address in big-endian order instead.
Add a new quirk that can be set on platforms with broken firmware and
use it to reverse the address when parsing the property so that the
underlying driver bug can be fixed.
Fixes: 5c0a1001c8 ("Bluetooth: hci_qca: Add helper to set device address")
Cc: stable@vger.kernel.org # 5.1
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 22cbf4f84c00da64196eb15034feee868e63eef0
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Feb 21 09:38:10 2024 -0500
Bluetooth: hci_sync: Use QoS to determine which PHY to scan
This used the hci_conn QoS to determine which PHY to scan when creating
a PA Sync.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Feb 16 16:20:11 2024 -0500
Bluetooth: hci_sync: Fix overwriting request callback
In a few cases the stack may generate commands as responses to events
which would happen to overwrite the sent_cmd, so this attempts to store
the request in req_skb so even if sent_cmd is replaced with a new
command the pending request will remain in stored in req_skb.
Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command execution")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit bba71ef13b20ef3373f6fdcd66fac35cd60f0bbb
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Feb 21 09:38:09 2024 -0500
Bluetooth: hci_sync: Use address filtering when HCI_PA_SYNC is set
If HCI_PA_SYNC flag is set it means there is a Periodic Advertising
Synchronization pending, so this attempts to locate the address passed
to HCI_OP_LE_PA_CREATE_SYNC and program it in the accept list so only
reports with that address are processed.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit 63298d6e752fc0ec7f5093860af8bc9f047b30c8
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Tue Jan 9 13:45:40 2024 -0500
Bluetooth: hci_core: Cancel request on command timeout
If command has timed out call __hci_cmd_sync_cancel to notify the
hci_req since it will inevitably cause a timeout.
This also rework the code around __hci_cmd_sync_cancel since it was
wrongly assuming it needs to cancel timer as well, but sometimes the
timers have not been started or in fact they already had timed out in
which case they don't need to be cancel yet again.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-61734
commit b14202aff5acba3b672704d792e821f02f8f562a
Author: Jonas Dreßler <verdre@v0yd.nl>
Date: Sun Jan 7 19:02:49 2024 +0100
Bluetooth: Add new state HCI_POWERING_DOWN
Add a new state HCI_POWERING_DOWN that indicates that the device is
currently powering down, this will be useful for the next commit.
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-63875
CVE: CVE-2024-50029
commit 881559af5f5c545f6828e7c74d79813eb886d523
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Tue Feb 13 09:59:32 2024 -0500
Bluetooth: hci_sync: Attempt to dequeue connection attempt
If connection is still queued/pending in the cmd_sync queue it means no
command has been generated and it should be safe to just dequeue the
callback when it is being aborted.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-63875
CVE: CVE-2024-50029
commit 505ea2b295929e7be2b4e1bc86ee31cb7862fb01
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Aug 9 13:43:53 2023 -0700
Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue
This adds functions to queue, dequeue and lookup into the cmd_sync
list.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-63875
CVE: CVE-2024-50029
commit 5f641f03abccddd1a37233ff1b8e774b9ff1f4e8
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Feb 9 09:08:06 2024 -0500
Bluetooth: hci_conn: Fix UAF Write in __hci_acl_create_connection_sync
This fixes the UAF on __hci_acl_create_connection_sync caused by
connection abortion, it uses the same logic as to LE_LINK which uses
hci_cmd_sync_cancel to prevent the callback to run if the connection is
abort prematurely.
Reported-by: syzbot+3f0a39be7a2035700868@syzkaller.appspotmail.com
Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-63875
CVE: CVE-2024-50029
commit bf98feea5b65ced367a871cf35fc044dedbcfb85
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Feb 7 15:26:20 2024 -0500
Bluetooth: hci_conn: Always use sk_timeo as conn_timeout
This aligns the use socket sk_timeo as conn_timeout when initiating a
connection and then use it when scheduling the resulting HCI command,
that way the command is actually aborted synchronously thus not
blocking commands generated by hci_abort_conn_sync to inform the
controller the connection is to be aborted.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-63875
CVE: CVE-2024-50029
commit 45340097ce6ea7e875674a5a7d24c95ecbc93ef9
Author: Jonas Dreßler <verdre@v0yd.nl>
Date: Tue Feb 6 12:08:13 2024 +0100
Bluetooth: hci_conn: Only do ACL connections sequentially
Pretty much all bluetooth chipsets only support paging a single device at
a time, and if they don't reject a secondary "Create Connection" request
while another is still ongoing, they'll most likely serialize those
requests in the firware.
With commit 4c67bc74f0 ("[Bluetooth] Support concurrent connect
requests") we started adding some serialization of our own in case the
adapter returns "Command Disallowed" HCI error.
This commit was using the BT_CONNECT2 state for the serialization, this
state is also used for a few more things (most notably to indicate we're
waiting for an inquiry to cancel) and therefore a bit unreliable. Also
not all BT firwares would respond with "Command Disallowed" on too many
connection requests, some will also respond with "Hardware Failure"
(BCM4378), and others will error out later and send a "Connect Complete"
event with error "Rejected Limited Resources" (Marvell 88W8897).
We can clean things up a bit and also make the serialization more reliable
by using our hci_sync machinery to always do "Create Connection" requests
in a sequential manner.
This is very similar to what we're already doing for establishing LE
connections, and it works well there.
Note that this causes a test failure in mgmt-tester (test "Pair Device
- Power off 1") because the hci_abort_conn_sync() changes the error we
return on timeout of the "Create Connection". We'll fix this on the
mgmt-tester side by adjusting the expected error for the test.
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/5068
bluetooth/l2cap: sync sock recv cb and release
JIRA: https://issues.redhat.com/browse/RHEL-51202
CVE: CVE-2024-41062
```
commit 89e856e124f9ae548572c56b1b70c2255705f8fe
Author: Edward Adam Davis <eadavis@qq.com>
Date: Sat Jun 15 09:45:54 2024 +0800
bluetooth/l2cap: sync sock recv cb and release
The problem occurs between the system call to close the sock and hci_rx_work,
where the former releases the sock and the latter accesses it without lock protection.
CPU0 CPU1
---- ----
sock_close hci_rx_work
l2cap_sock_release hci_acldata_packet
l2cap_sock_kill l2cap_recv_frame
sk_free l2cap_conless_channel
l2cap_sock_recv_cb
If hci_rx_work processes the data that needs to be received before the sock is
closed, then everything is normal; Otherwise, the work thread may access the
released sock when receiving data.
Add a chan mutex in the rx callback of the sock to achieve synchronization between
the sock release and recv cb.
Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.
Reported-and-tested-by: syzbot+b7f6f8c9303466e16c8a@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
```
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
Approved-by: José Ignacio Tornos Martínez <jtornosm@redhat.com>
Approved-by: Tony Camuso <tcamuso@redhat.com>
Approved-by: David Marlin <dmarlin@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: Rado Vrbovsky <rvrbovsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-51202
CVE: CVE-2024-41062
commit f1a8f402f13f94263cf349216c257b2985100927
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jun 24 09:42:09 2024 -0400
Bluetooth: L2CAP: Fix deadlock
This fixes the following deadlock introduced by 39a92a55be13
("bluetooth/l2cap: sync sock recv cb and release")
============================================
WARNING: possible recursive locking detected
6.10.0-rc3-g4029dba6b6f1 #6823 Not tainted
--------------------------------------------
kworker/u5:0/35 is trying to acquire lock:
ffff888002ec2510 (&chan->lock#2/1){+.+.}-{3:3}, at:
l2cap_sock_recv_cb+0x44/0x1e0
but task is already holding lock:
ffff888002ec2510 (&chan->lock#2/1){+.+.}-{3:3}, at:
l2cap_get_chan_by_scid+0xaf/0xd0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&chan->lock#2/1);
lock(&chan->lock#2/1);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/u5:0/35:
#0: ffff888002b8a940 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
process_one_work+0x750/0x930
#1: ffff888002c67dd0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
at: process_one_work+0x44e/0x930
#2: ffff888002ec2510 (&chan->lock#2/1){+.+.}-{3:3}, at:
l2cap_get_chan_by_scid+0xaf/0xd0
To fix the original problem this introduces l2cap_chan_lock at
l2cap_conless_channel to ensure that l2cap_sock_recv_cb is called with
chan->lock held.
Fixes: 89e856e124f9 ("bluetooth/l2cap: sync sock recv cb and release")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-38459
CVE: CVE-2024-36013
commit 84a4bb6548a29326564f0e659fb8064503ecc1c7
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon May 6 18:33:52 2024 -0400
Bluetooth: HCI: Remove HCI_AMP support
Since BT_HS has been remove HCI_AMP controllers no longer has any use so
remove it along with the capability of creating AMP controllers.
Since we no longer need to differentiate between AMP and Primary
controllers, as only HCI_PRIMARY is left, this also remove
hdev->dev_type altogether.
Fixes: e7b02296fb40 ("Bluetooth: Remove BT_HS")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-30099
commit e5469adb2a7e930d96813316592302d9f8f1df4e
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Jan 5 10:43:26 2024 -0500
Bluetooth: hci_sync: Fix accept_list when attempting to suspend
During suspend, only wakeable devices can be in acceptlist, so if the
device was previously added it needs to be removed otherwise the device
can end up waking up the system prematurely.
Fixes: 3b42055388c3 ("Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan")
Signed-off-by: Clancy Shang <clancy.shang@quectel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: David Marlin <dmarlin@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-30099
commit 6b3899be24b16ff8ee0cb25f0bd59b01b15ba1d1
Author: Jonas Dreßler <verdre@v0yd.nl>
Date: Tue Jan 2 19:08:08 2024 +0100
Bluetooth: hci_sync: Check the correct flag before starting a scan
There's a very confusing mistake in the code starting a HCI inquiry: We're
calling hci_dev_test_flag() to test for HCI_INQUIRY, but hci_dev_test_flag()
checks hdev->dev_flags instead of hdev->flags. HCI_INQUIRY is a bit that's
set on hdev->flags, not on hdev->dev_flags though.
HCI_INQUIRY equals the integer 7, and in hdev->dev_flags, 7 means
HCI_BONDABLE, so we were actually checking for HCI_BONDABLE here.
The mistake is only present in the synchronous code for starting an inquiry,
not in the async one. Also devices are typically bondable while doing an
inquiry, so that might be the reason why nobody noticed it so far.
Fixes: abfeea476c68 ("Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY")
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: David Marlin <dmarlin@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-30099
commit d4b70ba1eab450eff9c5ef536f07c01d424b7eda
Author: clancy shang <clancy.shang@quectel.com>
Date: Mon Dec 18 18:24:17 2023 +0800
Bluetooth: hci_sync: fix BR/EDR wakeup bug
when Bluetooth set the event mask and enter suspend, the controller
has hci mode change event coming, it cause controller can not enter
sleep mode. so it should to set the hci mode change event mask before
enter suspend.
Signed-off-by: clancy shang <clancy.shang@quectel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: David Marlin <dmarlin@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-30099
commit 78db544b5d276b70c6ea2c2909ffed96b10229a3
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Sep 6 14:13:35 2023 -0700
Bluetooth: hci_core: Remove le_restart_scan work
This removes le_restart_scan work and instead just disables controller
duplicate filtering when discovery result_filtering is enabled and
HCI_QUIRK_STRICT_DUPLICATE_FILTER is set.
Link: https://github.com/bluez/bluez/issues/573
Link: https://github.com/bluez/bluez/issues/572
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: David Marlin <dmarlin@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-30099
commit a254b90c9aac3d3d938a07e019773e35a977451b
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date: Wed Sep 6 16:59:54 2023 +0300
Bluetooth: ISO: Fix BIS cleanup
This fixes the master BIS cleanup procedure - as opposed to CIS cleanup,
no HCI disconnect command should be issued. A master BIS should only be
terminated by disabling periodic and extended advertising, and terminating
the BIG.
In case of a Broadcast Receiver, all BIS and PA connections can be
cleaned up by calling hci_conn_failed, since it contains all function
calls that are necessary for successful cleanup.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: David Marlin <dmarlin@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-17138
commit a1f6c3aef13c9e7f8d459bd464e9e34da1342c0c
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Aug 4 16:23:41 2023 -0700
Bluetooth: hci_sync: Introduce PTR_UINT/UINT_PTR macros
This introduces PTR_UINT/UINT_PTR macros and replace the use of
PTR_ERR/ERR_PTR.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-17138
commit a239110ee8e0b0aafa265f0d54f7a16744855e70
Author: Pauli Virtanen <pav@iki.fi>
Date: Sat Sep 30 15:53:32 2023 +0300
Bluetooth: hci_sync: always check if connection is alive before deleting
In hci_abort_conn_sync it is possible that conn is deleted concurrently
by something else, also e.g. when waiting for hdev->lock. This causes
double deletion of the conn, so UAF or conn_hash.list corruption.
Fix by having all code paths check that the connection is still in
conn_hash before deleting it, while holding hdev->lock which prevents
any races.
Log (when powering off while BAP streaming, occurs rarely):
=======================================================================
kernel BUG at lib/list_debug.c:56!
...
? __list_del_entry_valid (lib/list_debug.c:56)
hci_conn_del (net/bluetooth/hci_conn.c:154) bluetooth
hci_abort_conn_sync (net/bluetooth/hci_sync.c:5415) bluetooth
? __pfx_hci_abort_conn_sync+0x10/0x10 [bluetooth]
? lock_release+0x1d5/0x3c0
? hci_disconnect_all_sync.constprop.0+0xb2/0x230 [bluetooth]
? __pfx_lock_release+0x10/0x10
? __kmem_cache_free+0x14d/0x2e0
hci_disconnect_all_sync.constprop.0+0xda/0x230 [bluetooth]
? __pfx_hci_disconnect_all_sync.constprop.0+0x10/0x10 [bluetooth]
? hci_clear_adv_sync+0x14f/0x170 [bluetooth]
? __pfx_set_powered_sync+0x10/0x10 [bluetooth]
hci_set_powered_sync+0x293/0x450 [bluetooth]
=======================================================================
Fixes: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync")
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-17138
commit fbdc4bc47268953c80853489f696e02d61f9a2c6
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date: Thu Aug 17 09:44:27 2023 +0300
Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync
This commit implements defer setup support for the Broadcast Sink
scenario: By setting defer setup on a broadcast socket before calling
listen, the user is able to trigger the PA sync and BIG sync procedures
separately.
This is useful if the user first wants to synchronize to the periodic
advertising transmitted by a Broadcast Source, and trigger the BIG sync
procedure later on.
If defer setup is set, once a PA sync established event arrives, a new
hcon is created and notified to the ISO layer. A child socket associated
with the PA sync connection will be added to the accept queue of the
listening socket.
Once the accept call returns the fd for the PA sync child socket, the
user should call read on that fd. This will trigger the BIG create sync
procedure, and the PA sync socket will become a listening socket itself.
When the BIG sync established event is notified to the ISO layer, the
bis connections will be added to the accept queue of the PA sync parent.
The user should call accept on the PA sync socket to get the final bis
connections.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-17138
commit 5af69ab9bc623bd9293c5a931fb0827ed5201b5c
Author: Vlad Pruteanu <vlad.pruteanu@nxp.com>
Date: Tue Sep 12 09:33:29 2023 +0300
Bluetooth: ISO: Set CIS bit only for devices with CIS support
Currently the CIS bit that can be set by the host is set for any device
that has CIS or BIS support. In reality, devices that support BIS may not
allow that bit to be set and so, the HCI bring up fails for them.
This commit fixes this by only setting the bit for CIS capable devices.
Signed-off-by: Vlad Pruteanu <vlad.pruteanu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-17138
commit 94d9ba9f9888b748d4abd2aa1547af56ae85f772
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Aug 9 16:49:33 2023 -0700
Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync
Use-after-free can occur in hci_disconnect_all_sync if a connection is
deleted by concurrent processing of a controller event.
To prevent this the code now tries to iterate over the list backwards
to ensure the links are cleanup before its parents, also it no longer
relies on a cursor, instead it always uses the last element since
hci_abort_conn_sync is guaranteed to call hci_conn_del.
UAF crash log:
==================================================================
BUG: KASAN: slab-use-after-free in hci_set_powered_sync
(net/bluetooth/hci_sync.c:5424) [bluetooth]
Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124
CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W
6.5.0-rc1+ #10
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.16.2-1.fc38 04/01/2014
Workqueue: hci0 hci_cmd_sync_work [bluetooth]
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x90
print_report+0xcf/0x670
? __virt_addr_valid+0xdd/0x160
? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]
kasan_report+0xa6/0xe0
? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]
? __pfx_set_powered_sync+0x10/0x10 [bluetooth]
hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]
? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth]
? __pfx_lock_release+0x10/0x10
? __pfx_set_powered_sync+0x10/0x10 [bluetooth]
hci_cmd_sync_work+0x137/0x220 [bluetooth]
process_one_work+0x526/0x9d0
? __pfx_process_one_work+0x10/0x10
? __pfx_do_raw_spin_lock+0x10/0x10
? mark_held_locks+0x1a/0x90
worker_thread+0x92/0x630
? __pfx_worker_thread+0x10/0x10
kthread+0x196/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
</TASK>
Allocated by task 1782:
kasan_save_stack+0x33/0x60
kasan_set_track+0x25/0x30
__kasan_kmalloc+0x8f/0xa0
hci_conn_add+0xa5/0xa80 [bluetooth]
hci_bind_cis+0x881/0x9b0 [bluetooth]
iso_connect_cis+0x121/0x520 [bluetooth]
iso_sock_connect+0x3f6/0x790 [bluetooth]
__sys_connect+0x109/0x130
__x64_sys_connect+0x40/0x50
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 695:
kasan_save_stack+0x33/0x60
kasan_set_track+0x25/0x30
kasan_save_free_info+0x2b/0x50
__kasan_slab_free+0x10a/0x180
__kmem_cache_free+0x14d/0x2e0
device_release+0x5d/0xf0
kobject_put+0xdf/0x270
hci_disconn_complete_evt+0x274/0x3a0 [bluetooth]
hci_event_packet+0x579/0x7e0 [bluetooth]
hci_rx_work+0x287/0xaa0 [bluetooth]
process_one_work+0x526/0x9d0
worker_thread+0x92/0x630
kthread+0x196/0x1e0
ret_from_fork+0x2c/0x50
==================================================================
Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier")
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
Bastien Nocera
Rado Vrbovsky
CKI Backport Bot
David Marlin