| Message ID | 20220405173751.7269-1-dossche.niels@gmail.com |
|---|---|
| State | Accepted |
| Commit | 1072b8391c7c1e04722b8b9324aa8e2938a9ee7b |
| Headers | show |
| Series | [v2] Bluetooth: use hdev lock for accept_list and reject_list in conn req | expand |
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
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Marcel Holtmann <marcel@holtmann.org>: On Tue, 5 Apr 2022 19:37:52 +0200 you wrote: > 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. > > [...] Here is the summary with links: - [v2] Bluetooth: use hdev lock for accept_list and reject_list in conn req https://git.kernel.org/bluetooth/bluetooth-next/c/1072b8391c7c You are awesome, thank you!
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index abaabfae19cc..02a77f676da4 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -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)
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. Fixes: a55bd29d5227 ("Bluetooth: Add white list lookup for incoming connection requests") Signed-off-by: Niels Dossche <dossche.niels@gmail.com> --- 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(-)