mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical
@ 2026-10-21  9:35 Chun-Yi Lee
  2026-10-21 14:00 ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 3+ messages in thread
From: Chun-Yi Lee @ 2026-10-21  9:35 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-kernel, linux-bluetooth, Chun-Yi Lee

The 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys
are identical") patch be introduced since v5.13. Looks this patch can
handle the CVE-2021-37577 issue. However, it only checks if the full
64-byte public key (X and Y coordinates) is identical, which is
insufficient.

In CVE-2021-37577:
Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple
Pairing using the Passkey entry protocol in Bluetooth Core
Specifications 2.1 through 5.3 may permit an unauthenticated
man-in-the-middle attacker to identify the Passkey used during pairing
by reflection of a crafted public key with the same X coordinate as the
offered public key and by reflection of the authentication evidence of
the initiating device, potentially permitting this attacker to complete
authenticated pairing with the responding device using the correct
Passkey for the pairing session. This is a related issue to
CVE-2020-26558.

And base on spec, the remote and local public key should not have
the same X coordinate:

Bluetooth Core Specification Version: v5.4
(7.1 PHASE 1: PUBLIC KEY EXCHANGE)
"If the two public keys have the same X coordinate and neither is the
debug key (see [Vol 4] Part E, Section 7.6.4), each device should fail
the pairing process."

Bluetooth Core Specification Version: v6.0
(7.1 Phase 1: Public key exchange)
"If the two public keys have the same X coordinate and neither is the
debug key (see [Vol 4] Part E, Section 7.6.4), each device shall fail
the pairing process."

Update the check in smp_cmd_public_key() to only compare the 32-byte X
coordinate of the public keys, making the validation strictly compliant
with the specification and effectively mitigating CVE-2021-37577.

Fixes: 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys are identical")
Link: https://nvd.nist.gov/vuln/detail/cve-2021-37577
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
---
 net/bluetooth/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 2df303f6a38f..80128b31e631 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2734,7 +2734,7 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
 	 * not in use.
 	 */
 	if (!test_bit(SMP_FLAG_DEBUG_KEY, &smp->flags) &&
-	    !crypto_memneq(key, smp->local_pk, 64)) {
+	    !crypto_memneq(key, smp->local_pk, 32)) {
 		bt_dev_err(hdev, "Remote and local public keys are identical");
 		return SMP_DHKEY_CHECK_FAILED;
 	}
-- 
2.51.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical
  2026-10-21  9:35 [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical Chun-Yi Lee
@ 2026-10-21 14:00 ` Luiz Augusto von Dentz
  2026-10-23  7:17   ` joeyli
  0 siblings, 1 reply; 3+ messages in thread
From: Luiz Augusto von Dentz @ 2026-10-21 14:00 UTC (permalink / raw)
  To: Chun-Yi Lee; +Cc: linux-kernel, linux-bluetooth, Chun-Yi Lee

Hi Chun-Yi,

On Wed, Oct 21, 2026 at 5:35 AM Chun-Yi Lee <joeyli.kernel@gmail.com> wrote:
>
> The 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys
> are identical") patch be introduced since v5.13. Looks this patch can
> handle the CVE-2021-37577 issue. However, it only checks if the full
> 64-byte public key (X and Y coordinates) is identical, which is
> insufficient.
>
> In CVE-2021-37577:
> Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple
> Pairing using the Passkey entry protocol in Bluetooth Core
> Specifications 2.1 through 5.3 may permit an unauthenticated
> man-in-the-middle attacker to identify the Passkey used during pairing
> by reflection of a crafted public key with the same X coordinate as the
> offered public key and by reflection of the authentication evidence of
> the initiating device, potentially permitting this attacker to complete
> authenticated pairing with the responding device using the correct
> Passkey for the pairing session. This is a related issue to
> CVE-2020-26558.
>
> And base on spec, the remote and local public key should not have
> the same X coordinate:
>
> Bluetooth Core Specification Version: v5.4
> (7.1 PHASE 1: PUBLIC KEY EXCHANGE)
> "If the two public keys have the same X coordinate and neither is the
> debug key (see [Vol 4] Part E, Section 7.6.4), each device should fail
> the pairing process."
>
> Bluetooth Core Specification Version: v6.0
> (7.1 Phase 1: Public key exchange)
> "If the two public keys have the same X coordinate and neither is the
> debug key (see [Vol 4] Part E, Section 7.6.4), each device shall fail
> the pairing process."
>
> Update the check in smp_cmd_public_key() to only compare the 32-byte X
> coordinate of the public keys, making the validation strictly compliant
> with the specification and effectively mitigating CVE-2021-37577.
>
> Fixes: 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys are identical")
> Link: https://nvd.nist.gov/vuln/detail/cve-2021-37577
> Signed-off-by: Chun-Yi Lee <jlee@suse.com>
> ---
>  net/bluetooth/smp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index 2df303f6a38f..80128b31e631 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -2734,7 +2734,7 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
>          * not in use.
>          */
>         if (!test_bit(SMP_FLAG_DEBUG_KEY, &smp->flags) &&
> -           !crypto_memneq(key, smp->local_pk, 64)) {
> +           !crypto_memneq(key, smp->local_pk, 32)) {
>                 bt_dev_err(hdev, "Remote and local public keys are identical");
>                 return SMP_DHKEY_CHECK_FAILED;
>         }
> --
> 2.51.0

Sashiko is flagging a problem:

https://sashiko.dev/#/patchset/20261021093522.3536051-1-jlee%40suse.com

That said I do wonder if the check is only truly valid as an
initiator, since as a responder, this could be checked before
responding in the unlikely event that the X coordinate happens to be
the exact same as the initiator's (if that is even possible).


-- 
Luiz Augusto von Dentz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical
  2026-10-21 14:00 ` Luiz Augusto von Dentz
@ 2026-10-23  7:17   ` joeyli
  0 siblings, 0 replies; 3+ messages in thread
From: joeyli @ 2026-10-23  7:17 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: Chun-Yi Lee, linux-kernel, linux-bluetooth, jlee

Hi Luiz, 

Thanks for your review!

On Wed, Oct 21, 2026 at 10:00:41AM -0400, Luiz Augusto von Dentz wrote:
> Hi Chun-Yi,
> 
> On Wed, Oct 21, 2026 at 5:35 AM Chun-Yi Lee <joeyli.kernel@gmail.com> wrote:
> >
> > The 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys
> > are identical") patch be introduced since v5.13. Looks this patch can
> > handle the CVE-2021-37577 issue. However, it only checks if the full
> > 64-byte public key (X and Y coordinates) is identical, which is
> > insufficient.
> >
> > In CVE-2021-37577:
> > Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple
> > Pairing using the Passkey entry protocol in Bluetooth Core
> > Specifications 2.1 through 5.3 may permit an unauthenticated
> > man-in-the-middle attacker to identify the Passkey used during pairing
> > by reflection of a crafted public key with the same X coordinate as the
> > offered public key and by reflection of the authentication evidence of
> > the initiating device, potentially permitting this attacker to complete
> > authenticated pairing with the responding device using the correct
> > Passkey for the pairing session. This is a related issue to
> > CVE-2020-26558.
> >
> > And base on spec, the remote and local public key should not have
> > the same X coordinate:
> >
> > Bluetooth Core Specification Version: v5.4
> > (7.1 PHASE 1: PUBLIC KEY EXCHANGE)
> > "If the two public keys have the same X coordinate and neither is the
> > debug key (see [Vol 4] Part E, Section 7.6.4), each device should fail
> > the pairing process."
> >
> > Bluetooth Core Specification Version: v6.0
> > (7.1 Phase 1: Public key exchange)
> > "If the two public keys have the same X coordinate and neither is the
> > debug key (see [Vol 4] Part E, Section 7.6.4), each device shall fail
> > the pairing process."
> >
> > Update the check in smp_cmd_public_key() to only compare the 32-byte X
> > coordinate of the public keys, making the validation strictly compliant
> > with the specification and effectively mitigating CVE-2021-37577.
> >
> > Fixes: 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys are identical")
> > Link: https://nvd.nist.gov/vuln/detail/cve-2021-37577
> > Signed-off-by: Chun-Yi Lee <jlee@suse.com>
> > ---
> >  net/bluetooth/smp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> > index 2df303f6a38f..80128b31e631 100644
> > --- a/net/bluetooth/smp.c
> > +++ b/net/bluetooth/smp.c
> > @@ -2734,7 +2734,7 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
> >          * not in use.
> >          */
> >         if (!test_bit(SMP_FLAG_DEBUG_KEY, &smp->flags) &&
> > -           !crypto_memneq(key, smp->local_pk, 64)) {
> > +           !crypto_memneq(key, smp->local_pk, 32)) {
> >                 bt_dev_err(hdev, "Remote and local public keys are identical");
> >                 return SMP_DHKEY_CHECK_FAILED;
> >         }
> > --
> > 2.51.0
> 
> Sashiko is flagging a problem:
> 
> https://sashiko.dev/#/patchset/20261021093522.3536051-1-jlee%40suse.com

Thanks for your reminder! I will fix it.

> 
> That said I do wonder if the check is only truly valid as an
> initiator, since as a responder, this could be checked before
> responding in the unlikely event that the X coordinate happens to be
> the exact same as the initiator's (if that is even possible).
>

Honestly I'm not familiar with Bluetooth. How about the following change?
It also checks local pk before Responsor sends public key to
Initiator:

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 80128b31e631..d1786e398128 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1889,6 +1889,16 @@ static u8 sc_send_public_key(struct smp_chan *smp)
        }
 
 done:
+       /* Check if remote and local public keys are the same and debug key is
+        * not in use.
+        */
+       if (!test_bit(SMP_FLAG_DEBUG_KEY, &smp->flags) &&
+           !test_bit(SMP_FLAG_INITIATOR, &smp->flags) &&
+           !crypto_memneq(smp->remote_pk, smp->local_pk, 32)) {
+               bt_dev_err(hdev, "Remote and local public keys are identical");
+               return SMP_DHKEY_CHECK_FAILED;
+       }
+
        SMP_DBG("Local Public Key X: %32phN", smp->local_pk);
        SMP_DBG("Local Public Key Y: %32phN", smp->local_pk + 32);
 
@@ -2734,6 +2744,7 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
         * not in use.
         */
        if (!test_bit(SMP_FLAG_DEBUG_KEY, &smp->flags) &&
+           test_bit(SMP_FLAG_INITIATOR, &smp->flags) &&
            !crypto_memneq(key, smp->local_pk, 32)) {
                bt_dev_err(hdev, "Remote and local public keys are identical");
                return SMP_DHKEY_CHECK_FAILED;

Thanks a lot! 
Joey Lee

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-10-23  7:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-21  9:35 [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical Chun-Yi Lee
2026-10-21 14:00 ` Luiz Augusto von Dentz
2026-10-23  7:17   ` joeyli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®