Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring
Subsystems (2)
PATCH 1/1 Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring
hci_is_adv_monitoring's function documentation states that it must be called under the hdev lock. Paths that leads to an unlocked call are:discov_update => start_discovery => interleaved_discov => active_scan
and: discov_update => start_discovery => active_scan
The solution is to take the lock in active_scan during the duration of the call to hci_is_adv_monitoring.
---
Note:
I am currently working on a static analyser to detect missing locks using type-based static analysis as my master's thesis
in order to obtain my master's degree.
If you would like to have more details, please let me know. This was a reported case. I manually verified the report by looking at the code, so that I do not send wrong information or patches. After concluding that this seems to be a true positive, I created this patch. I have only managed to compile-test this patch on x86_64. The effect on a running system could be a potential race condition in exceptional cases. This issue was found on Linux v5.17.1.
net/bluetooth/hci_request.c | 2 ++ 1 file changed, 2 insertions(+)
net/bluetooth/hci_request.c +2 -0
@@ -2260,6 +2260,7 @@ static int active_scan(struct hci_request *req, unsigned long opt)if (err <0 ) own_addr_type =ADDR_LE_DEV_PUBLIC ; +hci_dev_lock (hdev);if (hci_is_adv_monitoring (hdev)) {/* Duplicate filter should be disabled when some advertisement * monitor is activated, otherwise AdvMon can only receive one
@@ -2276,6 +2277,7 @@ static int active_scan(struct hci_request *req, unsigned long opt)*/ filter_dup =LE_SCAN_FILTER_DUP_DISABLE ; } +hci_dev_unlock (hdev); hci_req_start_scan(req, LE_SCAN_ACTIVE, interval, hdev->le_scan_window_discovery, own_addr_type,
Signature · 1 line
2.35.1
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=630120
---Test result---
Test Summary:
CheckPatch PASS 0.93 seconds GitLint PASS 0.46 seconds SubjectPrefix PASS 0.29 seconds BuildKernel PASS 40.03 seconds BuildKernel32 PASS 35.93 seconds Incremental Build with patchesPASS 48.96 seconds TestRunner: Setup PASS 609.44 seconds TestRunner: l2cap-tester PASS 19.44 seconds TestRunner: bnep-tester PASS 7.62 seconds TestRunner: mgmt-tester PASS 129.20 seconds TestRunner: rfcomm-tester PASS 9.98 seconds TestRunner: sco-tester PASS 9.58 seconds TestRunner: smp-tester PASS 9.77 seconds TestRunner: userchan-tester PASS 7.95 seconds
---
Regards,
Linux Bluetooth
This patch was applied to bluetooth/bluetooth-next.git (master) by Marcel Holtmann <[email protected]>:
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master) by Marcel Holtmann <[email protected]>:
Quoted 9 lines · On Thu, 7 Apr 2022 20:06:52 +0200 you wrote:
hci_is_adv_monitoring's function documentation states that it must be called under the hdev lock. Paths that leads to an unlocked call are:
discov_update=>start_discovery=>interleaved_discov=>active_scan
and:discov_update=>start_discovery=>active_scanThe solution is to take the lock in
active_scanduring the duration of the call tohci_is_adv_monitoring.[...]
Here is the summary with links:
- Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring
https://git.kernel.org/bluetooth/bluetooth-next/c/e05c3c0e1b45
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html