Re: [PATCH] Bluetooth: use hdev lock for accept_list and reject_list in conn req

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/04/2022 19:18, Marcel Holtmann wrote:
> Hi Niels,
> 
>> All accesses (both read 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.
>>
>> 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.
> 
> this doesn’t belong in the commit message.

Hi Marcel
I'll remove it from the commit message.
I can write it in below the --- in the future such that it won't be included.

> 
>>
>> Fixes: a55bd29d5227 ("Bluetooth: Add white list lookup for incoming connection requests")
>> Signed-off-by: Niels Dossche <dossche.niels@xxxxxxxxx>
>> ---
>> net/bluetooth/hci_event.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index abaabfae19cc..b9038f24f46f 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -3222,8 +3222,11 @@ 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_dev_unlock(hdev);
>> 		hci_reject_conn(hdev, &ev->bdaddr);
>> 		return;
>> 	}
>> @@ -3236,14 +3239,13 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data,
>> 	    !hci_dev_test_flag(hdev, HCI_CONNECTABLE) &&
>> 	    !hci_bdaddr_list_lookup_with_flags(&hdev->accept_list, &ev->bdaddr,
>> 					       BDADDR_BREDR)) {
>> +		hci_dev_unlock(hdev);
>> 		hci_reject_conn(hdev, &ev->bdaddr);
>> 		return;
>> 	}
> 
> Can we use an exit goto-label instead. I am not a big fan of "unbalanced” _unlock statements.

I'll make a v2 and send it.

> 
>> 	/* 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);
> 
> Regards
> 
> Marcel
> 

Thanks
Niels



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux