Re: [PATCH] Bluetooth: SMP: Fail if the X coordinate of remote and local public keys are identical

[Luiz Augusto von Dentz]

Hi Chun-Yi,

On Wed, Oct 21, 2026 at 5:35 AM Chun-Yi Lee <joeyli.kernel@xxxxxxxxx> 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@xxxxxxxx>
> ---
>  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