Hi maintainers,
While updating our CI machines to 5.8 series kernel, we noticed some
regression in how Bluetooth LE Just-Works pairing works. In case Linux
acts as responder and another device tries to re-pair using Just-Works,
pairing fails due to DHKey check failure. This appears to be regression
from eed467b517e8 ("Bluetooth: fix passkey uninitialized when used").
Best regards,
Matias Karhumaa
Matias Karhumaa (1):
Bluetooth: Fix Just-Works re-pairing
net/bluetooth/smp.c | 37 +++++++++----------------------------
1 file changed, 9 insertions(+), 28 deletions(-)
--
2.25.1
Fix Just-Works pairing responder role in case where LTK already exists.
Currently when trying to initiate re-pairing from another device
against Linux using Just-Works, pairing fails due to DHKey check failure
on Linux side. This happens because mackey calculation is skipped
totally if LTK already exists due to logic flaw in
smp_cmd_pairing_random() function.
With this fix mackey is calculated right before requesting confirmation
for Just-Works pairing from userspace which in turn fixes the DHKey
calculation.
Fixes: eed467b517e8 ("Bluetooth: fix passkey uninitialized when used")
Signed-off-by: Matias Karhumaa <[email protected]>
---
net/bluetooth/smp.c | 37 +++++++++----------------------------
1 file changed, 9 insertions(+), 28 deletions(-)
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index b0c1ee110eff..c3ea50fcac6d 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2122,7 +2122,7 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
struct smp_chan *smp = chan->data;
struct hci_conn *hcon = conn->hcon;
u8 *pkax, *pkbx, *na, *nb, confirm_hint;
- u32 passkey;
+ u32 passkey = 0;
int err;
BT_DBG("conn %p", conn);
@@ -2174,24 +2174,6 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
smp_send_cmd(conn, SMP_CMD_PAIRING_RANDOM, sizeof(smp->prnd),
smp->prnd);
SMP_ALLOW_CMD(smp, SMP_CMD_DHKEY_CHECK);
-
- /* Only Just-Works pairing requires extra checks */
- if (smp->method != JUST_WORKS)
- goto mackey_and_ltk;
-
- /* If there already exists long term key in local host, leave
- * the decision to user space since the remote device could
- * be legitimate or malicious.
- */
- if (hci_find_ltk(hcon->hdev, &hcon->dst, hcon->dst_type,
- hcon->role)) {
- /* Set passkey to 0. The value can be any number since
- * it'll be ignored anyway.
- */
- passkey = 0;
- confirm_hint = 1;
- goto confirm;
- }
}
mackey_and_ltk:
@@ -2206,17 +2188,16 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
SMP_ALLOW_CMD(smp, SMP_CMD_DHKEY_CHECK);
}
return 0;
- }
-
- err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
- if (err)
- return SMP_UNSPECIFIED;
-
- confirm_hint = 0;
+ } else if (smp->method != JUST_WORKS) {
+ err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
+ if (err)
+ return SMP_UNSPECIFIED;
-confirm:
- if (smp->method == JUST_WORKS)
+ confirm_hint = 0;
+ } else {
+ /* Just-Works needs hint for userspace */
confirm_hint = 1;
+ }
err = mgmt_user_confirm_request(hcon->hdev, &hcon->dst, hcon->type,
hcon->dst_type, passkey, confirm_hint);
--
2.25.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=429269
---Test result---
##############################
Test: CheckPatch - FAIL
Bluetooth: Fix Just-Works re-pairing
WARNING: Unknown commit id 'eed467b517e8', maybe rebased or not pulled?
#17:
Fixes: eed467b517e8 ("Bluetooth: fix passkey uninitialized when used")
total: 0 errors, 1 warnings, 0 checks, 57 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
"[PATCH] Bluetooth: Fix Just-Works re-pairing" has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: CheckGitLint - PASS
##############################
Test: CheckBuildK - PASS
##############################
Test: CheckTestRunner: Setup - PASS
##############################
Test: CheckTestRunner: l2cap-tester - PASS
Total: 40, Passed: 34 (85.0%), Failed: 0, Not Run: 6
##############################
Test: CheckTestRunner: bnep-tester - PASS
Total: 1, Passed: 1 (100.0%), Failed: 0, Not Run: 0
##############################
Test: CheckTestRunner: mgmt-tester - PASS
Total: 416, Passed: 402 (96.6%), Failed: 0, Not Run: 14
##############################
Test: CheckTestRunner: rfcomm-tester - PASS
Total: 9, Passed: 9 (100.0%), Failed: 0, Not Run: 0
##############################
Test: CheckTestRunner: sco-tester - PASS
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: CheckTestRunner: smp-tester - PASS
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: CheckTestRunner: userchan-tester - PASS
Total: 3, Passed: 3 (100.0%), Failed: 0, Not Run: 0
---
Regards,
Linux Bluetooth
Hi Matias,
> Fix Just-Works pairing responder role in case where LTK already exists.
> Currently when trying to initiate re-pairing from another device
> against Linux using Just-Works, pairing fails due to DHKey check failure
> on Linux side. This happens because mackey calculation is skipped
> totally if LTK already exists due to logic flaw in
> smp_cmd_pairing_random() function.
>
> With this fix mackey is calculated right before requesting confirmation
> for Just-Works pairing from userspace which in turn fixes the DHKey
> calculation.
>
> Fixes: eed467b517e8 ("Bluetooth: fix passkey uninitialized when used")
> Signed-off-by: Matias Karhumaa <[email protected]>
> ---
> net/bluetooth/smp.c | 37 +++++++++----------------------------
> 1 file changed, 9 insertions(+), 28 deletions(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index b0c1ee110eff..c3ea50fcac6d 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -2122,7 +2122,7 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
> struct smp_chan *smp = chan->data;
> struct hci_conn *hcon = conn->hcon;
> u8 *pkax, *pkbx, *na, *nb, confirm_hint;
> - u32 passkey;
> + u32 passkey = 0;
> int err;
>
> BT_DBG("conn %p", conn);
> @@ -2174,24 +2174,6 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
> smp_send_cmd(conn, SMP_CMD_PAIRING_RANDOM, sizeof(smp->prnd),
> smp->prnd);
> SMP_ALLOW_CMD(smp, SMP_CMD_DHKEY_CHECK);
> -
> - /* Only Just-Works pairing requires extra checks */
> - if (smp->method != JUST_WORKS)
> - goto mackey_and_ltk;
> -
> - /* If there already exists long term key in local host, leave
> - * the decision to user space since the remote device could
> - * be legitimate or malicious.
> - */
> - if (hci_find_ltk(hcon->hdev, &hcon->dst, hcon->dst_type,
> - hcon->role)) {
> - /* Set passkey to 0. The value can be any number since
> - * it'll be ignored anyway.
> - */
> - passkey = 0;
> - confirm_hint = 1;
> - goto confirm;
> - }
> }
I have a concern if we just remove such a comment. I think the commit message needs a bit more explanatory and this needs a few more reviews.
Regards
Marcel
Hi Marcel,
> I have a concern if we just remove such a comment. I think the commit message needs a bit more explanatory and this needs a few more reviews.
Thanks for taking time to look into this. I have just sent v2
addressing your comments.
Best regards,
Matias Karhumaa