From: joeyli <jlee@suse.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Chun-Yi Lee <joeyli.kernel@gmail.com>,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
jlee@suse.com
Subject: Re: [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical
Date: Fri, 23 Oct 2026 15:17:24 +0800 [thread overview]
Message-ID: <atsKBPdEtsxMFP6r@linux-691t> (raw)
In-Reply-To: <CABBYNZ+7ro4EHt8DXL-Oo_tgN1bn5av_KkGtaXXU7YqoQ0vDxQ@mail.gmail.com>
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
prev parent reply other threads:[~2026-10-23 7:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 12:57 ` bluez.test.bot
2026-10-21 14:00 ` [PATCH] " Luiz Augusto von Dentz
2026-10-23 7:17 ` joeyli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atsKBPdEtsxMFP6r@linux-691t \
--to=jlee@suse.com \
--cc=joeyli.kernel@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.