This change is used to relieve CVE-2020-26555. The description of the
CVE:

Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification
1.0B through 5.2 may permit an unauthenticated nearby device to spoof
the BD_ADDR of the peer device to complete pairing without knowledge
of the PIN. [1]

The detail of this attack is in IEEE paper:
BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols
[2]

It's a reflection attack. Base on the paper, attacker can induce the
attacked target to generate null link key (zero key) without PIN code.

We can ignore null link key in the handler of "Link Key Notification
event" to relieve the attack. A similar implementation also shows in
btstack project. [3]

Closes: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
Closes: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
Closes: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3722 [3]
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
---
 net/bluetooth/hci_event.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 95816a938cea..e81b8d6c13ba 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4684,6 +4684,12 @@ static void hci_link_key_notify_evt(struct hci_dev *hdev, void *data,
 	bool persistent;
 	u8 pin_len = 0;
 
+	/* Ignore NULL link key against CVE-2020-26555 */
+	if (!memcmp(ev->link_key, ZERO_KEY, HCI_LINK_KEY_SIZE)) {
+		BT_DBG("Ignore NULL link key (ZERO KEY) for %pMR", &ev->bdaddr);
+		return;
+	}
+
 	bt_dev_dbg(hdev, "");
 
 	hci_dev_lock(hdev);
-- 
2.35.3

Hi Chun-Yi,

On Fri, Jul 14, 2023 at 9:14 AM Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
>
> This change is used to relieve CVE-2020-26555. The description of the
> CVE:
>
> Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification
> 1.0B through 5.2 may permit an unauthenticated nearby device to spoof
> the BD_ADDR of the peer device to complete pairing without knowledge
> of the PIN. [1]
>
> The detail of this attack is in IEEE paper:
> BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols
> [2]
>
> It's a reflection attack. Base on the paper, attacker can induce the
> attacked target to generate null link key (zero key) without PIN code.
>
> We can ignore null link key in the handler of "Link Key Notification
> event" to relieve the attack. A similar implementation also shows in
> btstack project. [3]
>
> Closes: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
> Closes: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
> Closes: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3722 [3]

Shouldn't the last 2 be using Link: instead?

> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> ---
>  net/bluetooth/hci_event.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 95816a938cea..e81b8d6c13ba 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -4684,6 +4684,12 @@ static void hci_link_key_notify_evt(struct hci_dev *hdev, void *data,
>         bool persistent;
>         u8 pin_len = 0;
>
> +       /* Ignore NULL link key against CVE-2020-26555 */
> +       if (!memcmp(ev->link_key, ZERO_KEY, HCI_LINK_KEY_SIZE)) {
> +               BT_DBG("Ignore NULL link key (ZERO KEY) for %pMR", &ev->bdaddr);

Please use bt_dev_dbg instead.

> +               return;
> +       }
> +
>         bt_dev_dbg(hdev, "");
>
>         hci_dev_lock(hdev);
> --
> 2.35.3
>


-- 
Luiz Augusto von Dentz

Hi Luiz Augusto von Dentz,

First, thanks for your review!

On Fri, Jul 14, 2023 at 11:44:28AM -0700, Luiz Augusto von Dentz wrote:
> Hi Chun-Yi,
> 
> On Fri, Jul 14, 2023 at 9:14 AM Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
> >
> > This change is used to relieve CVE-2020-26555. The description of the
> > CVE:
> >
> > Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification
> > 1.0B through 5.2 may permit an unauthenticated nearby device to spoof
> > the BD_ADDR of the peer device to complete pairing without knowledge
> > of the PIN. [1]
> >
> > The detail of this attack is in IEEE paper:
> > BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols
> > [2]
> >
> > It's a reflection attack. Base on the paper, attacker can induce the
> > attacked target to generate null link key (zero key) without PIN code.
> >
> > We can ignore null link key in the handler of "Link Key Notification
> > event" to relieve the attack. A similar implementation also shows in
> > btstack project. [3]
> >
> > Closes: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
> > Closes: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
> > Closes: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3722 [3]
> 
> Shouldn't the last 2 be using Link: instead?
> 

Sorry for I confused Link: with Closes:. I will change all of them to Link: tag

> > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> > ---
> >  net/bluetooth/hci_event.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 95816a938cea..e81b8d6c13ba 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -4684,6 +4684,12 @@ static void hci_link_key_notify_evt(struct hci_dev *hdev, void *data,
> >         bool persistent;
> >         u8 pin_len = 0;
> >
> > +       /* Ignore NULL link key against CVE-2020-26555 */
> > +       if (!memcmp(ev->link_key, ZERO_KEY, HCI_LINK_KEY_SIZE)) {
> > +               BT_DBG("Ignore NULL link key (ZERO KEY) for %pMR", &ev->bdaddr);
> 
> Please use bt_dev_dbg instead.
>

I see! I will use bt_dev_dbg.
 
> > +               return;
> > +       }
> > +
> >         bt_dev_dbg(hdev, "");
> >
> >         hci_dev_lock(hdev);
> > --
> > 2.35.3
> >

Thanks a lot!
Joey Lee