UPSTREAM: 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: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e2cb6b891ad2b8caa9131e3be70f45243df82a80)
BUG=b:187829884
TEST=none
Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Change-Id: I8e1a41d9126b51a892819cc103c98b16e5105bc9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2891996
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Yun-Hao Chung <howardchung@chromium.org>
1 file changed
