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 18b3256db76bd1130965acd99fbd38f87c3e6950
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Aug 21 14:41:52 2024 -0400
Bluetooth: hci_core: Fix not handling hibernation actions
This fixes not handling hibernation actions on suspend notifier so they
are treated in the same way as regular suspend actions.
Fixes: 9952d90ea2 ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND")
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 932021a11805b9da4bd6abf66fe233cccd59fe0e
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Aug 12 11:22:08 2024 -0400
Bluetooth: hci_core: Fix LE quote calculation
Function hci_sched_le needs to update the respective counter variable
inplace other the likes of hci_quote_sent would attempt to use the
possible outdated value of conn->{le_cnt,acl_cnt}.
Link: https://github.com/bluez/bluez/issues/915
Fixes: 73d80deb7b ("Bluetooth: prioritizing data over HCI")
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 df3d6a3e01fd82cb74b6bb309f7be71e728a3448
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Thu Jul 25 18:28:08 2024 -0400
Bluetooth: hci_event: Fix setting DISCOVERY_FINDING for passive scanning
DISCOVERY_FINDING shall only be set for active scanning as passive
scanning is not meant to generate MGMT Device Found events causing
discovering state to go out of sync since userspace would believe it
is discovering when in fact it is just passive scanning.
Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219088
Fixes: 2e2515c1ba38 ("Bluetooth: hci_event: Set DISCOVERY_FINDING on SCAN_ENABLED")
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 936daee9cf08c5e58c9a0fe687f52adb2d80e87d
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 1 17:10:41 2024 -0400
Bluetooth: Remove hci_request.{c,h}
This removes hci_request.{c,h} since it shall no longer be used.
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 f25b7fd36cc3a850e006aed686f5bbecd200de1b
Author: Ying Hsu <yinghsu@chromium.org>
Date: Wed May 29 08:00:00 2024 +0000
Bluetooth: Add vendor-specific packet classification for ISO data
When HCI raw sockets are opened, the Bluetooth kernel module doesn't
track CIS/BIS connections. User-space applications have to identify
ISO data by maintaining connection information and look up the mapping
for each ACL data packet received. Besides, btsnoop log captured in
kernel couldn't tell ISO data from ACL data in this case.
To avoid additional lookups, this patch introduces vendor-specific
packet classification for Intel BT controllers to distinguish
ISO data packets from ACL data packets.
Signed-off-by: Ying Hsu <yinghsu@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 c61e41121036aa610e904ef60f8520e10455ee8c
Author: Erick Archer <erick.archer@outlook.com>
Date: Sat May 18 10:30:39 2024 +0200
Bluetooth: hci_core: Prefer array indexing over pointer arithmetic
Refactor the list_for_each_entry() loop of hci_get_dev_list()
function to use array indexing instead of pointer arithmetic.
This way, the code is more readable and idiomatic.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Erick Archer <erick.archer@outlook.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-61734
commit 8f7dfe171c576aaec4911cc59feaed26d79c7c7f
Author: Erick Archer <erick.archer@outlook.com>
Date: Sat May 18 10:30:38 2024 +0200
Bluetooth: hci_core: Prefer struct_size over open coded arithmetic
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1][2].
As the "dl" variable is a pointer to "struct hci_dev_list_req" and this
structure ends in a flexible array:
struct hci_dev_list_req {
[...]
struct hci_dev_req dev_req[]; /* hci_dev_req structures */
};
the preferred way in the kernel is to use the struct_size() helper to
do the arithmetic instead of the calculation "size + count * size" in
the kzalloc() and copy_to_user() functions.
At the same time, 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).
In this case, it is important to note that the logic needs a little
refactoring to ensure that the "dev_num" member is initialized before
the first access to the flex array. Specifically, add the assignment
before the list_for_each_entry() loop.
Also remove the "size" variable as it is no longer needed.
This way, the code is more readable and safer.
This code was detected with the help of Coccinelle, and audited and
modified manually.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
Link: https://github.com/KSPP/linux/issues/160 [2]
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Erick Archer <erick.archer@outlook.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-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 21d74b6b4e82d27eead168d2b1ce3096937c0237
Author: Mahesh Talewad <mahesh.talewad@nxp.com>
Date: Thu May 2 12:01:23 2024 +0300
LE Create Connection command timeout increased to 20 secs
On our DUT, we can see that the host issues create connection cancel
command after 4-sec if there is no connection complete event for
LE create connection cmd.
As per core spec v5.3 section 7.8.5, advertisement interval range is-
Advertising_Interval_Min
Default : 0x0800(1.28s)
Time Range: 20ms to 10.24s
Advertising_Interval_Max
Default : 0x0800(1.28s)
Time Range: 20ms to 10.24s
If the remote device is using adv interval of > 4 sec, it is
difficult to make a connection with the current timeout value.
Also, with the default interval of 1.28 sec, we will get only
3 chances to capture the adv packets with the 4 sec window.
Hence we want to increase this timeout to 20sec.
Signed-off-by: Mahesh Talewad <mahesh.talewad@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-61734
commit 2e2515c1ba384ae44f6bf13dd64b9a0a950798c4
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Thu Mar 28 17:40:53 2024 -0400
Bluetooth: hci_event: Set DISCOVERY_FINDING on SCAN_ENABLED
This makes sure that discovery state is properly synchronized otherwise
reports may not generate MGMT DeviceFound events as it would be assumed
that it was not initiated by a discovery session.
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 7c2cc5b1db509fb6e4a20c182cfbaf94255e4a7c
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Thu Mar 28 15:46:01 2024 -0400
Bluetooth: Add proper definitions for scan interval and window
This adds proper definitions for scan interval and window and then make
use of them instead their values.
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 947ec0d002dce8577b655793dcc6fc78d67b7cb6
Author: Pauli Virtanen <pav@iki.fi>
Date: Sat Mar 2 19:06:23 2024 +0200
Bluetooth: fix use-after-free in accessing skb after sending it
hci_send_cmd_sync first sends skb and then tries to clone it. However,
the driver may have already freed the skb at that point.
Fix by cloning the sent_cmd cloned just above, instead of the original.
Log:
================================================================
BUG: KASAN: slab-use-after-free in __copy_skb_header+0x1a/0x240
...
Call Trace: ..
__skb_clone+0x59/0x2c0
hci_cmd_work+0x3b3/0x3d0 [bluetooth]
process_one_work+0x459/0x900
...
Allocated by task 129: ...
__alloc_skb+0x1ae/0x220
__hci_cmd_sync_sk+0x44c/0x7a0 [bluetooth]
__hci_cmd_sync_status+0x24/0xb0 [bluetooth]
set_cig_params_sync+0x778/0x7d0 [bluetooth]
...
Freed by task 0: ...
kmem_cache_free+0x157/0x3c0
__usb_hcd_giveback_urb+0x11e/0x1e0
usb_giveback_urb_bh+0x1ad/0x2a0
tasklet_action_common.isra.0+0x259/0x4a0
__do_softirq+0x15b/0x5a7
================================================================
Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback")
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-61734
commit 81137162bfaa7278785b24c1fd2e9e74f082e8e4
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Feb 28 10:49:26 2024 -0500
Bluetooth: hci_core: Fix possible buffer overflow
struct hci_dev_info has a fixed size name[8] field so in the event that
hdev->name is bigger than that strcpy would attempt to write past its
size, so this fixes this problem by switching to use strscpy.
Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings")
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 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 d77433cdd2524cb924a5ec0476429330e9ee9f0e
Author: Jonas Dreßler <verdre@v0yd.nl>
Date: Sun Jan 7 19:02:50 2024 +0100
Bluetooth: Disconnect connected devices before rfkilling adapter
On a lot of platforms (at least the MS Surface devices, M1 macbooks, and
a few ThinkPads) firmware doesn't do its job when rfkilling a device
and the bluetooth adapter is not actually shut down properly on rfkill.
This leads to connected devices remaining in connected state and the
bluetooth connection eventually timing out after rfkilling an adapter.
Use the rfkill hook in the HCI driver to go through the full power-off
sequence (including stopping scans and disconnecting devices) before
rfkilling it, just like MGMT_OP_SET_POWERED would do.
In case anything during the larger power-off sequence fails, make sure
the device is still closed and the rfkill ends up being effective in
the end.
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>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/4996
JIRA: https://issues.redhat.com/browse/RHEL-38459
CVE: CVE-2024-36013
```
Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
Extend a critical section to prevent chan from early freeing.
Also make the l2cap_connect() return type void. Nothing is using the
returned value but it is ugly to return a potentially freed pointer.
Making it void will help with backports because earlier kernels did use
the return value. Now the compile will break for kernels where this
patch is not a complete fix.
Call stack summary:
[use]
l2cap_bredr_sig_cmd
l2cap_connect
┌ mutex_lock(&conn->chan_lock);
│ chan = pchan->ops->new_connection(pchan); <- alloc chan
│ __l2cap_chan_add(conn, chan);
│ l2cap_chan_hold(chan);
│ list_add(&chan->list, &conn->chan_l); ... (1)
└ mutex_unlock(&conn->chan_lock);
chan->conf_state ... (4) <- use after free
[free]
l2cap_conn_del
┌ mutex_lock(&conn->chan_lock);
│ foreach chan in conn->chan_l: ... (2)
│ l2cap_chan_put(chan);
│ l2cap_chan_destroy
│ kfree(chan) ... (3) <- chan freed
└ mutex_unlock(&conn->chan_lock);
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in _test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
net/bluetooth/l2cap_core.c:4260
Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
Fixes: 73ffa904b7 ("Bluetooth: Move conf_{req,rsp} stuff to struct l2cap_chan")
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 4d7b41c0e43995b0e992b9f8903109275744b658)
```
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
Approved-by: Bastien Nocera <bnocera@redhat.com>
Approved-by: Marc Milgram <mmilgram@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 87be7b189b2c50d4b51512f59e4e97db4eedee8a
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Jul 1 12:07:46 2024 -0400
Bluetooth: Fix usage of __hci_cmd_sync_status
__hci_cmd_sync_status shall only be used if hci_req_sync_lock is _not_
required which is not the case of hci_dev_cmd so it needs to use
hci_cmd_sync_status which uses hci_req_sync_lock internally.
Fixes: f1a8f402f13f ("Bluetooth: L2CAP: Fix deadlock")
Reported-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-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-38459
CVE: CVE-2024-36013
commit 9c16d0c8d93e3d2a95c5ed927b061f244db75579
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon Jan 15 21:12:19 2024 +0100
Bluetooth: Remove usage of the deprecated ida_simple_xx() API
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_max() is inclusive. So a -1 has been added when needed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
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-51214
CVE: CVE-2024-41063
commit 0d151a103775dd9645c78c97f77d6e2a5298d913
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon Jun 10 20:00:32 2024 +0900
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
due to hci_dev_put() from hci_error_reset() can cause deadlock at
destroy_workqueue(), for hci_error_reset() is called from
hdev->req_workqueue which destroy_workqueue() needs to flush.
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
queued into hdev->workqueue and hdev->{power_on,error_reset} which are
queued into hdev->req_workqueue are no longer running by the moment
destroy_workqueue(hdev->workqueue);
destroy_workqueue(hdev->req_workqueue);
are called from hci_release_dev().
Call cancel_work_sync() on these work items from hci_unregister_dev()
as soon as hdev->list is removed from hci_dev_list.
Reported-by: syzbot <syzbot+da0a9c9721e36db712e8@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=da0a9c9721e36db712e8
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-30099
JIRA: https://issues.redhat.com/browse/RHEL-31828
CVE: CVE-2024-26801
commit 2449007d3f73b2842c9734f45f0aadb522daf592
Author: Ying Hsu <yinghsu@chromium.org>
Date: Thu Jan 4 11:56:32 2024 +0000
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
? init_wait_entry+0x31/0x31
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
process_one_work+0x1d8/0x33f
worker_thread+0x21b/0x373
kthread+0x13a/0x152
? pr_cont_work+0x54/0x54
? kthread_blkcg+0x31/0x31
ret_from_fork+0x1f/0x30
This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.
Fixes: c7741d16a5 ("Bluetooth: Perform a power cycle when receiving hardware error event")
Signed-off-by: Ying Hsu <yinghsu@chromium.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 a2bcd2b63271a93a695fabbfbf459c603d956d48
Author: Manish Mandlik <mmandlik@google.com>
Date: Fri Aug 4 11:14:45 2023 -0700
Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()
KSAN reports use-after-free in hci_add_adv_monitor().
While adding an adv monitor,
hci_add_adv_monitor() calls ->
msft_add_monitor_pattern() calls ->
msft_add_monitor_sync() calls ->
msft_le_monitor_advertisement_cb() calls in an error case ->
hci_free_adv_monitor() which frees the *moniter.
This is referenced by bt_dev_dbg() in hci_add_adv_monitor().
Fix the bt_dev_dbg() by using handle instead of monitor->handle.
Fixes: b747a83690c8 ("Bluetooth: hci_sync: Refactor add Adv Monitor")
Signed-off-by: Manish Mandlik <mmandlik@google.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 3f19ffb2f924db5b0925c77818d18ac1f6f08a44
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Thu Jul 13 13:41:31 2023 -0700
Bluetooth: af_bluetooth: Make BT_PKT_STATUS generic
This makes the handling of BT_PKT_STATUS more generic so it can be
reused by sockets other than SCO like BT_DEFER_SETUP, etc.
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 573ebae162111063eedc6c838a659ba628f66a0f
Author: Ying Hsu <yinghsu@chromium.org>
Date: Wed Jul 5 21:06:47 2023 +0000
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier
may still be accessing it, it can cause the program to crash.
Here's the call trace:
<4>[102152.653246] Call Trace:
<4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]
<4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]
<4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]
<4>[102152.653268] notifier_call_chain+0x43/0x6b
<4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69
<4>[102152.653273] __pm_notifier_call_chain+0x22/0x39
<4>[102152.653276] pm_suspend+0x287/0x57c
<4>[102152.653278] state_store+0xae/0xe5
<4>[102152.653281] kernfs_fop_write+0x109/0x173
<4>[102152.653284] __vfs_write+0x16f/0x1a2
<4>[102152.653287] ? selinux_file_permission+0xca/0x16f
<4>[102152.653289] ? security_file_permission+0x36/0x109
<4>[102152.653291] vfs_write+0x114/0x21d
<4>[102152.653293] __x64_sys_write+0x7b/0xdb
<4>[102152.653296] do_syscall_64+0x59/0x194
<4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while
processing it in hci_suspend_notifier to avoid potential crash
caused by the race condition.
Signed-off-by: Ying Hsu <yinghsu@chromium.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 6f55eea116ba3646fb5fbb31de703f8cf79d8214
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Jun 30 15:33:15 2023 -0700
Bluetooth: hci_sync: Don't double print name in add/remove adv_monitor
The hci_add_adv_monitor() hci_remove_adv_monitor() functions call
bt_dev_dbg() to print some debug statements. The bt_dev_dbg() macro
automatically adds in the device's name. That means that we shouldn't
include the name in the bt_dev_dbg() calls.
Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Signed-off-by: Douglas Anderson <dianders@chromium.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-17138
commit 181a42edddf51d5d9697ecdf365d72ebeab5afb0
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date: Wed Oct 11 17:57:31 2023 +0800
Bluetooth: Make handle of hci_conn be unique
The handle of new hci_conn is always HCI_CONN_HANDLE_MAX + 1 if
the handle of the first hci_conn entry in hci_dev->conn_hash->list
is not HCI_CONN_HANDLE_MAX + 1. Use ida to manage the allocation of
hci_conn->handle to make it be unique.
Fixes: 9f78191cc9f1 ("Bluetooth: hci_conn: Always allocate unique handles")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.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 dcda165706b9fbfd685898d46a6749d7d397e0c0
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Sep 15 14:42:27 2023 -0700
Bluetooth: hci_core: Fix build warnings
This fixes the following warnings:
net/bluetooth/hci_core.c: In function ‘hci_register_dev’:
net/bluetooth/hci_core.c:2620:54: warning: ‘%d’ directive output may
be truncated writing between 1 and 10 bytes into a region of size 5
[-Wformat-truncation=]
2620 | snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
| ^~
net/bluetooth/hci_core.c:2620:50: note: directive argument in the range
[0, 2147483647]
2620 | snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
| ^~~~~~~
net/bluetooth/hci_core.c:2620:9: note: ‘snprintf’ output between 5 and
14 bytes into a destination of size 8
2620 | snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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-2530
commit de6dfcefd107667ce2dbedf4d9337f5ed557a4a1
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Jun 30 15:33:14 2023 -0700
Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()
KASAN reports that there's a use-after-free in
hci_remove_adv_monitor(). Trawling through the disassembly, you can
see that the complaint is from the access in bt_dev_dbg() under the
HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because
msft_remove_monitor() can end up freeing the monitor
structure. Specifically:
hci_remove_adv_monitor() ->
msft_remove_monitor() ->
msft_remove_monitor_sync() ->
msft_le_cancel_monitor_advertisement_cb() ->
hci_free_adv_monitor()
Let's fix the problem by just stashing the relevant data when it's
still valid.
Fixes: 7cf5c2978f23 ("Bluetooth: hci_sync: Refactor remove Adv Monitor")
Signed-off-by: Douglas Anderson <dianders@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-2530
commit 195ef75e19287b4bc413da3e3e3722b030ac881e
Author: Pauli Virtanen <pav@iki.fi>
Date: Mon Jun 19 01:04:31 2023 +0300
Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync
hci_update_accept_list_sync iterates over hdev->pend_le_conns and
hdev->pend_le_reports, and waits for controller events in the loop body,
without holding hdev lock.
Meanwhile, these lists and the items may be modified e.g. by
le_scan_cleanup. This can invalidate the list cursor or any other item
in the list, resulting to invalid behavior (eg use-after-free).
Use RCU for the hci_conn_params action lists. Since the loop bodies in
hci_sync block and we cannot use RCU or hdev->lock for the whole loop,
copy list items first and then iterate on the copy. Only the flags field
is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we
read valid values.
Free params everywhere with hci_conn_params_free so the cleanup is
guaranteed to be done properly.
This fixes the following, which can be triggered e.g. by BlueZ new
mgmt-tester case "Add + Remove Device Nowait - Success", or by changing
hci_le_set_cig_params to always return false, and running iso-tester:
==================================================================
BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
<TASK>
dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107)
print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)
? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65)
? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
kasan_report (mm/kasan/report.c:538)
? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780)
? mutex_lock (kernel/locking/mutex.c:282)
? __pfx_mutex_lock (kernel/locking/mutex.c:282)
? __pfx_mutex_unlock (kernel/locking/mutex.c:538)
? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861)
hci_cmd_sync_work (net/bluetooth/hci_sync.c:306)
process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399)
worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538)
? __pfx_worker_thread (kernel/workqueue.c:2480)
kthread (kernel/kthread.c:376)
? __pfx_kthread (kernel/kthread.c:331)
ret_from_fork (arch/x86/entry/entry_64.S:314)
</TASK>
Allocated by task 31:
kasan_save_stack (mm/kasan/common.c:46)
kasan_set_track (mm/kasan/common.c:52)
__kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383)
hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277)
hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589)
hci_connect_cis (net/bluetooth/hci_conn.c:2266)
iso_connect_cis (net/bluetooth/iso.c:390)
iso_sock_connect (net/bluetooth/iso.c:899)
__sys_connect (net/socket.c:2003 net/socket.c:2020)
__x64_sys_connect (net/socket.c:2027)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
Freed by task 15:
kasan_save_stack (mm/kasan/common.c:46)
kasan_set_track (mm/kasan/common.c:52)
kasan_save_free_info (mm/kasan/generic.c:523)
__kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244)
__kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800)
hci_conn_params_del (net/bluetooth/hci_core.c:2323)
le_scan_cleanup (net/bluetooth/hci_conn.c:202)
process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399)
worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538)
kthread (kernel/kthread.c:376)
ret_from_fork (arch/x86/entry/entry_64.S:314)
==================================================================
Fixes: e8907f76544f ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3")
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-2530
commit 3673952cf0c6cf81b06c66a0b788abeeb02ff3ae
Author: Min Li <lm0963hack@gmail.com>
Date: Mon Aug 7 19:07:41 2023 +0800
Bluetooth: Fix potential use-after-free when clear keys
Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in
hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu()
call.
Fixes: d7d41682ef ("Bluetooth: Fix Suspicious RCU usage warnings")
Signed-off-by: Min Li <lm0963hack@gmail.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-2530
commit 1857c19941c87eb36ad47f22a406be5dfe5eff9f
Author: Zhengping Jiang <jiangzp@google.com>
Date: Wed May 24 17:11:58 2023 -0700
Bluetooth: hci_sync: add lock to protect HCI_UNREGISTER
When the HCI_UNREGISTER flag is set, no jobs should be scheduled. Fix
potential race when HCI_UNREGISTER is set after the flag is tested in
hci_cmd_sync_queue.
Fixes: 0b94f2651f56 ("Bluetooth: hci_sync: Fix queuing commands when HCI_UNREGISTER is set")
Signed-off-by: Zhengping Jiang <jiangzp@google.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-2530
commit c5d2b6fa26b5b8386a9cc902cdece3a46bef2bd2
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Tue May 30 13:48:44 2023 -0700
Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk
Similar to commit 0f7d9b31ce7a ("netfilter: nf_tables: fix use-after-free
in nft_set_catchall_destroy()"). We can not access k after kfree_rcu()
call.
Cc: stable@vger.kernel.org
Signed-off-by: Min Li <lm0963hack@gmail.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-2530
commit f419863588217f76eaf754e1dfce21ea7fcb026d
Author: Archie Pusaka <apusaka@chromium.org>
Date: Thu Apr 20 20:23:36 2023 +0800
Bluetooth: Cancel sync command before suspend and power off
Some of the sync commands might take a long time to complete, e.g.
LE Create Connection when the peer device isn't responding might take
20 seconds before it times out. If suspend command is issued during
this time, it will need to wait for completion since both commands are
using the same sync lock.
This patch cancel any running sync commands before attempting to
suspend or adapter power off.
Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Ying Hsu <yinghsu@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-2530
commit 9695ef876fd122cb7bbc04a4a93b8727d2e36bda
Author: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date: Thu Mar 30 09:58:23 2023 -0700
Bluetooth: Add support for hci devcoredump
Add devcoredump APIs to hci core so that drivers only have to provide
the dump skbs instead of managing the synchronization and timeouts.
The devcoredump APIs should be used in the following manner:
- hci_devcoredump_init is called to allocate the dump.
- hci_devcoredump_append is called to append any skbs with dump data
OR hci_devcoredump_append_pattern is called to insert a pattern.
- hci_devcoredump_complete is called when all dump packets have been
sent OR hci_devcoredump_abort is called to indicate an error and
cancel an ongoing dump collection.
The high level APIs just prepare some skbs with the appropriate data and
queue it for the dump to process. Packets part of the crashdump can be
intercepted in the driver in interrupt context and forwarded directly to
the devcoredump APIs.
Internally, there are 5 states for the dump: idle, active, complete,
abort and timeout. A devcoredump will only be in active state after it
has been initialized. Once active, it accepts data to be appended,
patterns to be inserted (i.e. memset) and a completion event or an abort
event to generate a devcoredump. The timeout is initialized at the same
time the dump is initialized (defaulting to 10s) and will be cleared
either when the timeout occurs or the dump is complete or aborted.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Manish Mandlik <mmandlik@google.com>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@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-2530
commit 876e78104f23ce9267822757a63562a609b126c3
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri Feb 24 15:43:31 2023 -0800
Bluetooth: hci_core: Detect if an ACL packet is in fact an ISO packet
Because some transports don't have a dedicated type for ISO packets
(see 14202eff214e1e941fefa0366d4c3bc4b1a0d500) they may use ACL type
when in fact they are ISO packets.
In the past this was left for the driver to detect such thing but it
creates a problem when using the likes of btproxy when used by a VM as
the host would not be aware of the connection the guest is doing it
won't be able to detect such behavior, so this make bt_recv_frame
detect when it happens as it is the common interface to all drivers
including guest VMs.
Fixes: 14202eff214e ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Bastien Nocera <bnocera@redhat.com>
Patrick Talbert
CKI Backport Bot
Bastien Nocera
Rado Vrbovsky
David Marlin