bluetooth: eliminate the potential race condition when removing the HCI controller
There is a possible race condition vulnerability between issuing a HCI
command and removing the cont. Specifically, functions hci_req_sync()
and hci_dev_do_close() can race each other like below:
thread-A in hci_req_sync() | thread-B in hci_dev_do_close()
| hci_req_sync_lock(hdev);
test_bit(HCI_UP, &hdev->flags); |
... | test_and_clear_bit(HCI_UP, &hdev->flags)
hci_req_sync_lock(hdev); |
|
In this commit we alter the sequence in function hci_req_sync(). Hence,
the thread-A cannot issue th.
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Cc: Marcel Holtmann <marcel@holtmann.org>
Fixes: 7c6a329e44
("[Bluetooth] Fix regression from using default link policy")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
9204ff9486
commit
e2cb6b891a
|
@ -272,12 +272,16 @@ int hci_req_sync(struct hci_dev *hdev, int (*req)(struct hci_request *req,
|
|||
{
|
||||
int ret;
|
||||
|
||||
if (!test_bit(HCI_UP, &hdev->flags))
|
||||
return -ENETDOWN;
|
||||
|
||||
/* Serialize all requests */
|
||||
hci_req_sync_lock(hdev);
|
||||
/* check the state after obtaing the lock to protect the HCI_UP
|
||||
* against any races from hci_dev_do_close when the controller
|
||||
* gets removed.
|
||||
*/
|
||||
if (test_bit(HCI_UP, &hdev->flags))
|
||||
ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);
|
||||
else
|
||||
ret = -ENETDOWN;
|
||||
hci_req_sync_unlock(hdev);
|
||||
|
||||
return ret;
|
||||
|
|
Loading…
Reference in New Issue