09 Jan, 2021
1 commit
-
commit a31489d2a368d2f9225ed6a6f595c63bc7d10de8 upstream.
During controller initialization, an LE Set RPA Timeout command is sent
to the controller if supported. However, the value checked to determine
if the command is supported is incorrect. Page 1921 of the Bluetooth
Core Spec v5.2 shows that bit 2 of octet 35 of the Supported_Commands
field corresponds to the LE Set RPA Timeout command, but currently
bit 6 of octet 35 is checked. This patch checks the correct value
instead.This issue led to the error seen in the following btmon output during
initialization of an adapter (rtl8761b) and prevented initialization
from completing.< HCI Command: LE Set Resolvable Private Address Timeout (0x08|0x002e) plen 2
Timeout: 900 seconds
> HCI Event: Command Complete (0x0e) plen 4
LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 2
Status: Unsupported Remote Feature / Unsupported LMP Feature (0x1a)
= Close Index: 00:E0:4C:6B:E5:03The error did not appear when running with this patch.
Signed-off-by: Edward Vear
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
Cc: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
30 Dec, 2020
3 commits
-
[ Upstream commit f6b8c6b5543983e9de29dc14716bfa4eb3f157c4 ]
This commit add the invalid check for connected socket, without it will
causes the following crash due to sco_pi(sk)->conn being NULL:KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
CPU: 3 PID: 4284 Comm: test_sco Not tainted 5.10.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
RIP: 0010:sco_sock_getsockopt+0x45d/0x8e0
Code: 48 c1 ea 03 80 3c 02 00 0f 85 ca 03 00 00 49 8b 9d f8 04 00 00 48 b8 00
00 00 00 00 fc ff df 48 8d 7b 50 48 89 fa 48 c1 ea 03 b6 04 02 84
c0 74 08 3c 03 0f 8e b5 03 00 00 8b 43 50 48 8b 0c
RSP: 0018:ffff88801bb17d88 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83a4ecdf
RDX: 000000000000000a RSI: ffffc90002fce000 RDI: 0000000000000050
RBP: 1ffff11003762fb4 R08: 0000000000000001 R09: ffff88810e1008c0
R10: ffffffffbd695dcf R11: fffffbfff7ad2bb9 R12: 0000000000000000
R13: ffff888018ff1000 R14: dffffc0000000000 R15: 000000000000000d
FS: 00007fb4f76c1700(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555e3b7a938 CR3: 00000001117be001 CR4: 0000000000770ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
? sco_skb_put_cmsg+0x80/0x80
? sco_skb_put_cmsg+0x80/0x80
__sys_getsockopt+0x12a/0x220
? __ia32_sys_setsockopt+0x150/0x150
? syscall_enter_from_user_mode+0x18/0x50
? rcu_read_lock_bh_held+0xb0/0xb0
__x64_sys_getsockopt+0xba/0x150
? syscall_enter_from_user_mode+0x1d/0x50
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9Fixes: 0fc1a726f897 ("Bluetooth: sco: new getsockopt options BT_SNDMTU/BT_RCVMTU")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
Reviewed-by: Luiz Augusto Von Dentz
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
Signed-off-by: Sasha Levin -
[ Upstream commit 1fb17dfc258ff6208f7873cc7b8e40e27515d2d5 ]
When adding device to white list the device is added to resolving list
also. It has to be added only when HCI_ENABLE_LL_PRIVACY flag is set.
HCI_ENABLE_LL_PRIVACY flag has to be tested before adding/deleting devices
to resolving list. use_ll_privacy macro is used only to check if controller
supports LL_Privacy.https://bugzilla.kernel.org/show_bug.cgi?id=209745
Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist")
Signed-off-by: Sathish Narasimman
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin -
[ Upstream commit 6dfccd13db2ff2b709ef60a50163925d477549aa ]
AMP_MGR is getting derefernced in hci_phy_link_complete_evt(), when called
from hci_event_packet() and there is a possibility, that hcon->amp_mgr may
not be found when accessing after initialization of hcon.- net/bluetooth/hci_event.c:4945
The bug seems to get triggered in this line:bredr_hcon = hcon->amp_mgr->l2cap_conn->hcon;
Fix it by adding a NULL check for the hcon->amp_mgr before checking the ev-status.
Fixes: d5e911928bd8 ("Bluetooth: AMP: Process Physical Link Complete evt")
Reported-and-tested-by: syzbot+0bef568258653cff272f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=0bef568258653cff272f
Signed-off-by: Anmol Karn
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
26 Dec, 2020
1 commit
-
commit f7e0e8b2f1b0a09b527885babda3e912ba820798 upstream.
`num_reports` is not being properly checked. A malformed event packet with
a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
of bounds. Fix it.Cc: stable@vger.kernel.org
Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct Advertising Report events")
Reported-and-tested-by: syzbot+24ebd650e20bd263ca01@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01
Signed-off-by: Peilin Ye
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman
30 Oct, 2020
1 commit
-
There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: Gustavo A. R. Silva
30 Sep, 2020
1 commit
-
…etooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2020-09-29Here's the main bluetooth-next pull request for 5.10:
- Multiple fixes to suspend/resume handling
- Added mgmt events for controller suspend/resume state
- Improved extended advertising support
- btintel: Enhanced support for next generation controllers
- Added Qualcomm Bluetooth SoC WCN6855 support
- Several other smaller fixes & improvements
====================Signed-off-by: David S. Miller <davem@davemloft.net>
26 Sep, 2020
4 commits
-
This checks if BT_HS is enabled relecting it on MGMT_SETTING_HS instead
of always reporting it as supported.Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Marcel Holtmann -
Bluetooth High Speed requires hardware support which is very uncommon
nowadays since HS has not pickup interest by the industry.Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Marcel Holtmann -
Only sockets will have the chan->data set to an actual sk, channels
like A2MP would have its own data which would likely cause a crash when
calling sk_filter, in order to fix this a new callback has been
introduced so channels can implement their own filtering if necessary.Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Marcel Holtmann -
This fixes various places where a stack variable is used uninitialized.
Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Marcel Holtmann
25 Sep, 2020
1 commit
-
During system powercycle when trying to get the random address
hci_get_random_address set own_addr_type as 0x01. In which if we enable
ll_privacy it is supposed to be 0x03.Signed-off-by: Sathish Narasimman
Signed-off-by: Marcel Holtmann
20 Sep, 2020
3 commits
-
Currently the code auto-creates hci_conn only if the remote address has
been discovered before. This may not be the case. For example, the
remote device may trigger connection after reboot at already-paired
state so there is no inquiry result found, but it is still correct to
create the hci_conn when Connection Complete event is received.A better guard is to check against bredr allowlist. Devices in the
allowlist have been given permission to auto-connect.Fixes: 4f40afc6c764 ("Bluetooth: Handle BR/EDR devices during suspend")
Signed-off-by: Sonny Sasaka
Reviewed-by: Abhishek Pandit-Subedi
Signed-off-by: Marcel Holtmann -
Set scan parameters when there is at least one Advertisement monitor.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek Pandit-Subedi
Reviewed-by: Miao-chen Chou
Signed-off-by: Marcel Holtmann -
This fixes the count of Adv monitor upon monitor removal.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-remove command on one
console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other.Signed-off-by: Miao-chen Chou
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Signed-off-by: Marcel Holtmann
19 Sep, 2020
1 commit
-
Drop repeated words in net/bluetooth/.
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Alexey Kuznetsov
Cc: Hideaki YOSHIFUJI
Signed-off-by: David S. Miller
15 Sep, 2020
1 commit
-
Currently, the controller will continue advertising when the system
enters suspend. This patch makes sure that all advertising instances are
paused when entering suspend, and resumed when suspend exits.The Advertising and Suspend/Resume test suites were both run on this
change on 4.19 kernel with both hardware offloaded multi-advertising and
software rotated multi-advertising. In addition, a new test was added
that performs the following steps:
* Register 3 advertisements via bluez RegisterAdvertisement
* Verify reception of all advertisements by remote peer
* Enter suspend on DUT
* Verify failure to receive all advertisements by remote peer
* Exit suspend on DUT
* Verify reception of all advertisements by remote peerSigned-off-by: Daniel Winkler
Reviewed-by: Abhishek Pandit-Subedi
Signed-off-by: Marcel Holtmann
13 Sep, 2020
5 commits
-
Emit controller suspend and resume events when we are ready for suspend
and we've resumed from suspend.The controller suspend event will report whatever suspend state was
successfully entered. The controller resume event will check the first
HCI event that was received after we finished preparing for suspend and,
if it was a connection event, store the address of the peer that caused
the event. If it was not a connection event, we mark the wake reason as
an unexpected event.Here is a sample btmon trace with these events:
@ MGMT Event: Controller Suspended (0x002d) plen 1
Suspend state: Page scanning and/or passive scanning (2)@ MGMT Event: Controller Resumed (0x002e) plen 8
Wake reason: Remote wake due to peer device connection (2)
LE Address: CD:F3:CD:13:C5:9A (OUI CD-F3-CD)Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Miao-chen Chou
Signed-off-by: Marcel Holtmann -
Update device disconnect event with reason 0x5 to indicate that device
disconnected because the controller is suspending.Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Miao-chen Chou
Reviewed-by: Sonny Sasaka
Signed-off-by: Marcel Holtmann -
Add the controller suspend and resume events, which will signal when
Bluetooth has completed preparing for suspend and when it's ready for
resume.Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Miao-chen Chou
Reviewed-by: Sonny Sasaka
Signed-off-by: Marcel Holtmann -
Only set extended scan response only when it exists. Otherwise, clear
the scan response data.Per the core spec v5.2, Vol 4, Part E, 7.8.55
If the advertising set is non-scannable and the Host uses this command
other than to discard existing data, the Controller shall return the
error code Invalid HCI Command Parameters (0x12).On WCN3991, the controller correctly responds with Invalid Parameters
when this is sent. That error causes __hci_req_hci_power_on to fail
with -EINVAL and LE devices can't connect because background scanning
isn't configured.Here is an hci trace of where this issue occurs during power on:
< HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25
Handle: 0x00
Properties: 0x0010
Use legacy advertising PDUs: ADV_NONCONN_IND
Min advertising interval: 181.250 msec (0x0122)
Max advertising interval: 181.250 msec (0x0122)
Channel map: 37, 38, 39 (0x07)
Own address type: Random (0x01)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect...
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 5
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 9 dbm (0x09)
< HCI Command: LE Set Advertising Set Random Address (0x08|0x0035) plen 7
Advertising handle: 0x00
Advertising random address: 08:FD:55:ED:22:28 (OUI 08-FD-55)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Set Random Address (0x08|0x0035) ncmd
Status: Success (0x00)
< HCI Command: LE Set Extended Scan Response Data (0x08|0x0038) plen 35
Handle: 0x00
Operation: Complete scan response data (0x03)
Fragment preference: Minimize fragmentation (0x01)
Data length: 0x0d
Name (short): Chromebook
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Scan Response Data (0x08|0x0038) ncmd 1
Status: Invalid HCI Command Parameters (0x12)Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Daniel Winkler
Signed-off-by: Marcel Holtmann -
Since l2cap_sock_teardown_cb doesn't acquire the channel lock before
setting the socket as zapped, it could potentially race with
l2cap_sock_release which frees the socket. Thus, wait until the cleanup
is complete before marking the socket as zapped.This race was reproduced on a JBL GO speaker after the remote device
rejected L2CAP connection due to resource unavailability.Here is a dmesg log with debug logs from a repro of this bug:
[ 3465.424086] Bluetooth: hci_core.c:hci_acldata_packet() hci0 len 16 handle 0x0003 flags 0x0002
[ 3465.424090] Bluetooth: hci_conn.c:hci_conn_enter_active_mode() hcon 00000000cfedd07d mode 0
[ 3465.424094] Bluetooth: l2cap_core.c:l2cap_recv_acldata() conn 000000007eae8952 len 16 flags 0x2
[ 3465.424098] Bluetooth: l2cap_core.c:l2cap_recv_frame() len 12, cid 0x0001
[ 3465.424102] Bluetooth: l2cap_core.c:l2cap_raw_recv() conn 000000007eae8952
[ 3465.424175] Bluetooth: l2cap_core.c:l2cap_sig_channel() code 0x03 len 8 id 0x0c
[ 3465.424180] Bluetooth: l2cap_core.c:l2cap_connect_create_rsp() dcid 0x0045 scid 0x0000 result 0x02 status 0x00
[ 3465.424189] Bluetooth: l2cap_core.c:l2cap_chan_put() chan 000000006acf9bff orig refcnt 4
[ 3465.424196] Bluetooth: l2cap_core.c:l2cap_chan_del() chan 000000006acf9bff, conn 000000007eae8952, err 111, state BT_CONNECT
[ 3465.424203] Bluetooth: l2cap_sock.c:l2cap_sock_teardown_cb() chan 000000006acf9bff state BT_CONNECT
[ 3465.424221] Bluetooth: l2cap_core.c:l2cap_chan_put() chan 000000006acf9bff orig refcnt 3
[ 3465.424226] Bluetooth: hci_core.h:hci_conn_drop() hcon 00000000cfedd07d orig refcnt 6
[ 3465.424234] BUG: spinlock bad magic on CPU#2, kworker/u17:0/159
[ 3465.425626] Bluetooth: hci_sock.c:hci_sock_sendmsg() sock 000000002bb0cb64 sk 00000000a7964053
[ 3465.430330] lock: 0xffffff804410aac0, .magic: 00000000, .owner: /-1, .owner_cpu: 0
[ 3465.430332] Causing a watchdog bite!Signed-off-by: Abhishek Pandit-Subedi
Reported-by: Balakrishna Godavarthi
Reviewed-by: Manish Mandlik
Signed-off-by: Marcel Holtmann
11 Sep, 2020
5 commits
-
For new advertising features, it will be important for userspace to
know the capabilities of the controller and kernel. If the controller
and kernel support extended advertising, we include flags indicating
hardware offloading support and support for setting tx power of adv
instances.In the future, vendor-specific commands may allow the setting of tx
power in advertising instances, but for now this feature is only
marked available if extended advertising is supported.This change is manually verified in userspace by ensuring the
advertising manager's supported_flags field is updated with new flags on
hatch chromebook (ext advertising supported).Signed-off-by: Daniel Winkler
Signed-off-by: Marcel Holtmann -
Here we make sure we properly report the number of supported
advertising slots when we are using hardware offloading. If no
hardware offloading is available, we default this value to
HCI_MAX_ADV_INSTANCES for use in software rotation as before.This change has been tested on kukui (no ext adv) and hatch (ext adv)
chromebooks by verifying "SupportedInstances" shows 5 (the default) and
6 (slots supported by controller), respectively.Signed-off-by: Daniel Winkler
Signed-off-by: Marcel Holtmann -
This patch defines new getsockopt options BT_SNDMTU/BT_RCVMTU
for SCO socket to be compatible with other bluetooth sockets.
These new options return the same value as option SCO_OPTIONS
which is already present on existing kernels.Signed-off-by: Joseph Hwang
Reviewed-by: Alain Michaud
Reviewed-by: Abhishek Pandit-Subedi
Reviewed-by: Pali Rohár
Signed-off-by: Marcel Holtmann -
Unregister_pm_notifier is a blocking call so suspend tasks should be
cleared beforehand. Otherwise, the notifier will wait for completion
before returning (and we encounter a 2s timeout on resume).Fixes: 0e9952804ec9c8 (Bluetooth: Clear suspend tasks on unregister)
Signed-off-by: Abhishek Pandit-Subedi
Signed-off-by: Marcel Holtmann -
read_adv_mon_features() is leaking memory. Free `rp` before returning.
Fixes: e5e1e7fd470c ("Bluetooth: Add handler of MGMT_OP_READ_ADV_MONITOR_FEATURES")
Reported-and-tested-by: syzbot+f7f6e564f4202d8601c6@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7f6e564f4202d8601c6
Signed-off-by: Peilin Ye
Signed-off-by: Marcel Holtmann
01 Sep, 2020
1 commit
-
While unregistering, make sure to clear the suspend tasks before
cancelling the work. If the unregister is called during resume from
suspend, this will unnecessarily add 2s to the resume time otherwise.Fixes: 4e8c36c3b0d73d (Bluetooth: Fix suspend notifier race)
Signed-off-by: Abhishek Pandit-Subedi
Signed-off-by: Marcel Holtmann
08 Aug, 2020
1 commit
-
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.In "kzalloc()", the z is meaningful and an important part of what the
caller wants.In "kzfree()", the z is actively detrimental, because maybe in the
future we really _might_ want to use that "memfill(0xdeadbeef)" or
something. The "zero" part of the interface isn't even _relevant_.The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.The renaming is done by using the command sequence:
git grep -w --name-only kzfree |\
xargs sed -i 's/kzfree/kfree_sensitive/'followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]Suggested-by: Joe Perches
Signed-off-by: Waiman Long
Signed-off-by: Andrew Morton
Acked-by: David Howells
Acked-by: Michal Hocko
Acked-by: Johannes Weiner
Cc: Jarkko Sakkinen
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: Joe Perches
Cc: Matthew Wilcox
Cc: David Rientjes
Cc: Dan Carpenter
Cc: "Jason A . Donenfeld"
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds
02 Aug, 2020
1 commit
-
Resolved kernel/bpf/btf.c using instructions from merge commit
69138b34a7248d2396ab85c8652e20c0c39beabaSigned-off-by: David S. Miller
01 Aug, 2020
2 commits
-
net/bluetooth/sco.c: In function ‘sco_sock_setsockopt’:
net/bluetooth/sco.c:862:3: error: cannot convert to a pointer type
862 | if (get_user(opt, (u32 __user *)optval)) {
| ^~Signed-off-by: David S. Miller
-
…etooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2020-07-31Here's the main bluetooth-next pull request for 5.9:
- Fix firmware filenames for Marvell chipsets
- Several suspend-related fixes
- Addedd mgmt commands for runtime configuration
- Multiple fixes for Qualcomm-based controllers
- Add new monitoring feature for mgmt
- Fix handling of legacy cipher (E4) together with security level 4
- Add support for Realtek 8822CE controller
- Fix issues with Chinese controllers using fake VID/PID values
- Multiple other smaller fixes & improvements
====================Signed-off-by: David S. Miller <davem@davemloft.net>
31 Jul, 2020
4 commits
-
The flag CRYPTO_ALG_INTERNAL is not meant to be used outside of
the Crypto API. It isn't needed here anyway.Signed-off-by: Herbert Xu
Signed-off-by: Johan Hedberg -
Increment the mgmt revision due to the recently added new commands.
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
When an LE connection is requested and an RPA update is needed via
hci_connect_le_scan, the default scanning parameters are used rather
than the connect parameters. This leads to significant delays in the
connection establishment process when using lower duty cycle scanning
parameters.The patch simply looks at the pended connection list when trying to
determine which scanning parameters should be used.Before:
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
#378 [hci0] 1659.247156
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
PHYs: 0x01
Entry 0: LE 1M
Type: Passive (0x00)
Interval: 367.500 msec (0x024c)
Window: 37.500 msec (0x003c)After:
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
#39 [hci0] 7.422109
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
PHYs: 0x01
Entry 0: LE 1M
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 60.000 msec (0x0060)Signed-off-by: Alain Michaud
Reviewed-by: Abhishek Pandit-Subedi
Reviewed-by: Yu Liu
Signed-off-by: Marcel Holtmann -
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
content. In particular, this was reproduced with an advertisement of
229 bytes filled with 'A'. See stack trace below.This is fixed by not catching ext_adv as legacy adv are only cached to
be able to concatenate a scanable adv with its scan response before
sending it up through mgmt.With ext_adv, this is no longer necessary.
general protection fault: 0000 [#1] SMP PTI
CPU: 6 PID: 205 Comm: kworker/u17:0 Not tainted 5.4.0-37-generic #41-Ubuntu
Hardware name: Dell Inc. XPS 15 7590/0CF6RR, BIOS 1.7.0 05/11/2020
Workqueue: hci0 hci_rx_work [bluetooth]
RIP: 0010:hci_bdaddr_list_lookup+0x1e/0x40 [bluetooth]
Code: ff ff e9 26 ff ff ff 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 07 48 89 e5 48 39 c7 75 0a eb 24 48 8b 00 48 39 f8 74 1c 44 8b 06 39 40 10 75 ef 44 0f b7 4e 04 66 44 39 48 14 75 e3 38 50 16 75
RSP: 0018:ffffbc6a40493c70 EFLAGS: 00010286
RAX: 4141414141414141 RBX: 000000000000001b RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9903e76c100f RDI: ffff9904289d4b28
RBP: ffffbc6a40493c70 R08: 0000000093570362 R09: 0000000000000000
R10: 0000000000000000 R11: ffff9904344eae38 R12: ffff9904289d4000
R13: 0000000000000000 R14: 00000000ffffffa3 R15: ffff9903e76c100f
FS: 0000000000000000(0000) GS:ffff990434580000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007feed125a000 CR3: 00000001b860a003 CR4: 00000000003606e0
Call Trace:
process_adv_report+0x12e/0x560 [bluetooth]
hci_le_meta_evt+0x7b2/0xba0 [bluetooth]
hci_event_packet+0x1c29/0x2a90 [bluetooth]
hci_rx_work+0x19b/0x360 [bluetooth]
process_one_work+0x1eb/0x3b0
worker_thread+0x4d/0x400
kthread+0x104/0x140Fixes: c215e9397b00 ("Bluetooth: Process extended ADV report event")
Reported-by: Andy Nguyen
Reported-by: Linus Torvalds
Reported-by: Balakrishna Godavarthi
Signed-off-by: Alain Michaud
Tested-by: Sonny Sasaka
Acked-by: Marcel Holtmann
Signed-off-by: Linus Torvalds
30 Jul, 2020
4 commits
-
This patch adds support to enable the use of RPA Address resolution
using expermental feature mgmt command.Signed-off-by: Sathish Narasimman
Signed-off-by: Marcel Holtmann -
Enable RPA timeout during bluetooth initialization.
The RPA timeout value is used from hdev, which initialized from
debug_fsSigned-off-by: Sathish Narasimman
Signed-off-by: Marcel Holtmann -
In this patch if le_create_conn process is started restrict to
disable address resolution and same is disabled during
le_enh_connection_completeSigned-off-by: Sathish Narasimman
Signed-off-by: Marcel Holtmann -
When address resolution is enabled and set_privacy is enabled let's
use own address type as 0x03Signed-off-by: Sathish Narasimman
Signed-off-by: Marcel Holtmann