diff mbox series

Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring

Message ID 20220407180651.14871-1-dossche.niels@gmail.com (mailing list archive)
State Accepted
Commit e05c3c0e1b45737c58292d59ade9fcb51ee95272
Headers show
Series Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success
tedd_an/checkpatch success Checkpatch PASS
tedd_an/gitlint success Gitlint PASS
tedd_an/subjectprefix success PASS
tedd_an/buildkernel success Build Kernel PASS
tedd_an/buildkernel32 success Build Kernel32 PASS
tedd_an/incremental_build success Pass
tedd_an/testrunnersetup success Test Runner Setup PASS
tedd_an/testrunnerl2cap-tester success Total: 40, Passed: 40 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnerbnep-tester success Total: 1, Passed: 1 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnermgmt-tester success Total: 493, Passed: 493 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnerrfcomm-tester success Total: 10, Passed: 10 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnersco-tester success Total: 12, Passed: 12 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunnersmp-tester success Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
tedd_an/testrunneruserchan-tester success Total: 4, Passed: 4 (100.0%), Failed: 0, Not Run: 0

Commit Message

Niels Dossche April 7, 2022, 6:06 p.m. UTC
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.

Fixes: c32d624640fd ("Bluetooth: disable filter dup when scan for adv monitor")
Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
---

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(+)

Comments

bluez.test.bot@gmail.com April 7, 2022, 7:12 p.m. UTC | #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
patchwork-bot+bluetooth@kernel.org April 22, 2022, 9:30 a.m. UTC | #2
Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Marcel Holtmann <marcel@holtmann.org>:

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_scan
> 
> The solution is to take the lock in active_scan during the duration of
> the call to hci_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!
diff mbox series

Patch

diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 42c8047a9897..f4afe482e300 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -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,