linux.git/net/bluetooth/mgmt.c, branch v5.13

Bluetooth: Allow Microsoft extension to indicate curve validation

2021-04-08T10:26:34+00:00

Some controllers don't support the Simple Pairing Options feature that
can indicate the support for P-192 and P-256 public key validation.
However they might support the Microsoft vendor extension that can
indicate the validiation capability as well.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Do not set cur_adv_instance in adv param MGMT request

2021-04-06T08:43:26+00:00

We set hdev->cur_adv_instance in the adv param MGMT request to allow the
callback to the hci param request to set the tx power to the correct
instance. Now that the callbacks use the advertising handle from the hci
request (as they should), this workaround is no longer necessary.

Furthermore, this change resolves a race condition that is more
prevalent when using the extended advertising MGMT calls - if
hdev->cur_adv_instance is set in the params request, then when the data
request is called, we believe our new instance is already active. This
treats it as an update and immediately schedules the instance with the
controller, which has a potential race with the software rotation adv
update. By not setting hdev->cur_adv_instance too early, the new
instance is queued as it should be, to be used when the rotation comes
around again.

This change is tested on harrison peak to confirm that it resolves the
race condition on registration, and that there is no regression in
single- and multi-advertising automated tests.

Reviewed-by: Miao-chen Chou 
Signed-off-by: Daniel Winkler 
Signed-off-by: Marcel Holtmann

Bluetooth: Increment management interface revision

2021-03-26T21:05:22+00:00

Increment the mgmt revision due to recent changes.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Move the advertisement monitor events to correct list

2021-03-26T21:05:22+00:00

The list of trusted events should contain the advertisement monitor
events and not the untrusted one, so move entries to the correct list.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Add missing entries for PHY configuration commands

2021-03-26T21:05:22+00:00

The list of supported mgmt commands for PHY configuration is missing, so
just add them.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Fix wrong opcode error for read advertising features

2021-03-26T19:58:13+00:00

The read advertising features error handling returns false the opcode
for the set advertising command.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Fix mgmt status for LL Privacy experimental feature

2021-03-26T19:58:13+00:00

The return error when trying to change the setting when a controller is
powered up, shall be MGMT_STATUS_REJECTED. However instead now the error
MGMT_STATUS_NOT_POWERED is used which is exactly the opposite.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Allow scannable adv with extended MGMT APIs

2021-03-03T17:14:38+00:00

An issue was found, where if a bluetooth client requests a broadcast
advertisement with scan response data, it will not be properly
registered with the controller. This is because at the time that the
hci_cp_le_set_scan_param structure is created, the scan response will
not yet have been received since it comes in a second MGMT call. With
empty scan response, the request defaults to a non-scannable PDU type.
On some controllers, the subsequent scan response request will fail due
to incorrect PDU type, and others will succeed and not use the scan
response.

This fix allows the advertising parameters MGMT call to include a flag
to let the kernel know whether a scan response will be coming, so that
the correct PDU type is used in the first place. A bluetoothd change is
also incoming to take advantage of it.

To test this, I created a broadcast advertisement with scan response
data and registered it on the hatch chromebook. Without this change, the
request fails, and with it will succeed.

Reviewed-by: Alain Michaud 
Reviewed-by: Sonny Sasaka 
Reviewed-by: Miao-chen Chou 
Signed-off-by: Daniel Winkler 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix crash in mgmt_add_adv_patterns_monitor_complete

2021-02-03T13:32:46+00:00

If hci_add_adv_monitor is a pending command(e.g. forward to
msft_add_monitor_pattern), it is possible that
mgmt_add_adv_patterns_monitor_complete gets called before
cmd->user_data gets set, which will cause a crash when we
try to get the moniter handle through cmd->user_data in
mgmt_add_adv_patterns_monitor_complete.

This moves the cmd->user_data assignment earlier than
hci_add_adv_monitor.

RIP: 0010:mgmt_add_adv_patterns_monitor_complete+0x82/0x187 [bluetooth]
Code: 1e bf 03 00 00 00 be 52 00 00 00 4c 89 ea e8 9e
e4 02 00 49 89 c6 48 85 c0 0f 84 06 01 00 00 48 89 5d b8 4c 89 fb 4d 8b
7e 30 <41> 0f b7 47 18 66 89 45 c0 45 84 e4 75 5a 4d 8b 56 28 48 8d 4d
c8
RSP: 0018:ffffae81807dbcb8 EFLAGS: 00010286
RAX: ffff91c4bdf723c0 RBX: 0000000000000000 RCX: ffff91c4e5da5b80
RDX: ffff91c405680000 RSI: 0000000000000052 RDI: ffff91c49d654c00
RBP: ffffae81807dbd00 R08: ffff91c49fb157e0 R09: ffff91c49fb157e0
R10: 000000000002a4f0 R11: ffffffffc0819cfd R12: 0000000000000000
R13: ffff91c405680000 R14: ffff91c4bdf723c0 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff91c4ea300000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 0000000133612002 CR4:
00000000003606e0
Call Trace:
 ? msft_le_monitor_advertisement_cb+0x111/0x141
[bluetooth]
 hci_event_packet+0x425e/0x631c [bluetooth]
 ? printk+0x59/0x73
 ? __switch_to_asm+0x41/0x70
 ?
msft_le_set_advertisement_filter_enable_cb+0xa6/0xa6 [bluetooth]
 ? bt_dbg+0xb4/0xbb [bluetooth]
 ? __switch_to_asm+0x41/0x70
 hci_rx_work+0x101/0x319 [bluetooth]
 process_one_work+0x257/0x506
 worker_thread+0x10d/0x284
 kthread+0x14c/0x154
 ? process_one_work+0x506/0x506
 ? kthread_blkcg+0x2c/0x2c
 ret_from_fork+0x1f/0x40

Reviewed-by: Miao-chen Chou 
Reviewed-by: Manish Mandlik 
Reviewed-by: Archie Pusaka 
Signed-off-by: Howard Chung 
Signed-off-by: Marcel Holtmann

Bluetooth: advmon offload MSFT remove monitor

2021-01-25T15:07:36+00:00

Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.

Signed-off-by: Archie Pusaka 
Reviewed-by: Miao-chen Chou 
Reviewed-by: Yun-Hao Chung 
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Marcel Holtmann