Bluetooth: use hdev lock for accept_list and reject_list in conn req

All accesses (both reads and modifications) to hdev->{accept,reject}_list are protected by hdev lock, except the ones in hci_conn_request_evt. This can cause a race condition in the form of a list corruption.
The solution is to protect these lists in hci_conn_request_evt as well.

I was unable to find the exact commit that introduced the issue for the reject list, I was only able to find it for the accept list.

---

Changes in v2:
- edited commit message to exclude note
- used an exit goto label instead

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 both compile-tested this patch and runtime-tested 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_event.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

index abaabfae19cc..02a77f676da4 100644
@@ -3222,10 +3222,12 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data,
 		return;
 	}
 
+	hci_dev_lock(hdev);
+
 	if (hci_bdaddr_list_lookup(&hdev->reject_list, &ev->bdaddr,
 				   BDADDR_BREDR)) {
 		hci_reject_conn(hdev, &ev->bdaddr);
-		return;
+		goto unlock;
 	}
 
 	/* Require HCI_CONNECTABLE or an accept list entry to accept the

@@ -3237,13 +3239,11 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data,
 	    !hci_bdaddr_list_lookup_with_flags(&hdev->accept_list, &ev->bdaddr,
 					       BDADDR_BREDR)) {
 		hci_reject_conn(hdev, &ev->bdaddr);
-		return;
+		goto unlock;
 	}
 
 	/* Connection accepted */
 
-	hci_dev_lock(hdev);
-
 	ie = hci_inquiry_cache_lookup(hdev, &ev->bdaddr);
 	if (ie)
 		memcpy(ie->data.dev_class, ev->dev_class, 3);

@@ -3255,8 +3255,7 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data,
 				    HCI_ROLE_SLAVE);
 		if (!conn) {
 			bt_dev_err(hdev, "no memory for new connection");
-			hci_dev_unlock(hdev);
-			return;
+			goto unlock;
 		}
 	}
 

@@ -3296,6 +3295,10 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data,
 		conn->state = BT_CONNECT2;
 		hci_connect_cfm(conn, 0);
 	}
+
+	return;
+unlock:
+	hci_dev_unlock(hdev);
 }
 
 static u8 hci_to_mgmt_reason(u8 err)

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=629298

---Test result---

Test Summary:

CheckPatch                    PASS      1.57 seconds
GitLint                       PASS      0.99 seconds
SubjectPrefix                 PASS      0.85 seconds
BuildKernel                   PASS      30.97 seconds
BuildKernel32                 PASS      27.76 seconds
Incremental Build with patchesPASS      38.25 seconds
TestRunner: Setup             PASS      466.52 seconds
TestRunner: l2cap-tester      PASS      15.59 seconds
TestRunner: bnep-tester       PASS      6.09 seconds
TestRunner: mgmt-tester       PASS      103.36 seconds
TestRunner: rfcomm-tester     PASS      7.67 seconds
TestRunner: sco-tester        PASS      7.56 seconds
TestRunner: smp-tester        PASS      7.52 seconds
TestRunner: userchan-tester   PASS      6.33 seconds

---
Regards,
Linux Bluetooth