Hi Johan,
> The SMP code expects hdev to be unlocked since e.g. crypto functions
> will try to (re)lock it. Therefore, we need to release the lock before
> calling into smp.c from mgmt.c. Without this we risk a deadlock whenever
> the smp_user_confirm_reply() function is called.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx>
> ---
> net/bluetooth/mgmt.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index 6107e037cd8e..af8e0a6243b7 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -3031,8 +3031,13 @@ static int user_pairing_resp(struct sock *sk, struct hci_dev *hdev,
> }
>
> if (addr->type == BDADDR_LE_PUBLIC || addr->type == BDADDR_LE_RANDOM) {
> - /* Continue with pairing via SMP */
> + /* Continue with pairing via SMP. The hdev lock must be
> + * released as SMP may try to recquire it for crypto
> + * purposes.
> + */
> + hci_dev_unlock(hdev);
> err = smp_user_confirm_reply(conn, mgmt_op, passkey);
> + hci_dev_lock(hdev);
providing a __smp_user_confirm_reply that operates on a locked hdev and where the crypto functions do not take the hdev lock is not possible.
The lock/unlock seems a bit counterproductive here.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
