--- /dev/null
+From c7f59461f5a78994613afc112cdd73688aef9076 Mon Sep 17 00:00:00 2001
+From: Ziyang Xuan <william.xuanziyang@huawei.com>
+Date: Wed, 4 Oct 2023 20:42:24 +0800
+Subject: Bluetooth: Fix a refcnt underflow problem for hci_conn
+
+From: Ziyang Xuan <william.xuanziyang@huawei.com>
+
+commit c7f59461f5a78994613afc112cdd73688aef9076 upstream.
+
+Syzbot reports a warning as follows:
+
+WARNING: CPU: 1 PID: 26946 at net/bluetooth/hci_conn.c:619
+hci_conn_timeout+0x122/0x210 net/bluetooth/hci_conn.c:619
+...
+Call Trace:
+ <TASK>
+ process_one_work+0x884/0x15c0 kernel/workqueue.c:2630
+ process_scheduled_works kernel/workqueue.c:2703 [inline]
+ worker_thread+0x8b9/0x1290 kernel/workqueue.c:2784
+ kthread+0x33c/0x440 kernel/kthread.c:388
+ ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
+ ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
+ </TASK>
+
+It is because the HCI_EV_SIMPLE_PAIR_COMPLETE event handler drops
+hci_conn directly without check Simple Pairing whether be enabled. But
+the Simple Pairing process can only be used if both sides have the
+support enabled in the host stack.
+
+Add hci_conn_ssp_enabled() for hci_conn in HCI_EV_IO_CAPA_REQUEST and
+HCI_EV_SIMPLE_PAIR_COMPLETE event handlers to fix the problem.
+
+Fixes: 0493684ed239 ("[Bluetooth] Disable disconnect timer during Simple Pairing")
+Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_event.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -4342,7 +4342,7 @@ static void hci_io_capa_request_evt(stru
+ hci_dev_lock(hdev);
+
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
+- if (!conn)
++ if (!conn || !hci_conn_ssp_enabled(conn))
+ goto unlock;
+
+ hci_conn_hold(conn);
+@@ -4577,7 +4577,7 @@ static void hci_simple_pair_complete_evt
+ hci_dev_lock(hdev);
+
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
+- if (!conn)
++ if (!conn || !hci_conn_ssp_enabled(conn))
+ goto unlock;
+
+ /* Reset the authentication requirement to unknown */
--- /dev/null
+From 33155c4aae5260475def6f7438e4e35564f4f3ba Mon Sep 17 00:00:00 2001
+From: "Lee, Chun-Yi" <jlee@suse.com>
+Date: Sun, 1 Oct 2023 16:59:31 +0800
+Subject: Bluetooth: hci_event: Ignore NULL link key
+
+From: Lee, Chun-Yi <jlee@suse.com>
+
+commit 33155c4aae5260475def6f7438e4e35564f4f3ba upstream.
+
+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. The paper mentioned that attacker can induce
+the attacked target to generate null link key (zero key) without PIN
+code. In BR/EDR, the key generation is actually handled in the controller
+which is below HCI.
+
+Thus, 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]
+
+v3: Drop the connection when null link key be detected.
+
+v2:
+- Used Link: tag instead of Closes:
+- Used bt_dev_dbg instead of BT_DBG
+- Added Fixes: tag
+
+Cc: stable@vger.kernel.org
+Fixes: 55ed8ca10f35 ("Bluetooth: Implement link key handling for the management interface")
+Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
+Link: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
+Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3722 [3]
+Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_event.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3816,6 +3816,15 @@ static void hci_link_key_notify_evt(stru
+ if (!conn)
+ goto unlock;
+
++ /* Ignore NULL link key against CVE-2020-26555 */
++ if (!memcmp(ev->link_key, ZERO_KEY, HCI_LINK_KEY_SIZE)) {
++ bt_dev_dbg(hdev, "Ignore NULL link key (ZERO KEY) for %pMR",
++ &ev->bdaddr);
++ hci_disconnect(conn, HCI_ERROR_AUTH_FAILURE);
++ hci_conn_drop(conn);
++ goto unlock;
++ }
++
+ hci_conn_hold(conn);
+ conn->disc_timeout = HCI_DISCONN_TIMEOUT;
+ hci_conn_drop(conn);
--- /dev/null
+From 1ffc6f8cc33268731fcf9629fc4438f6db1191fc Mon Sep 17 00:00:00 2001
+From: "Lee, Chun-Yi" <jlee@suse.com>
+Date: Sun, 1 Oct 2023 16:59:58 +0800
+Subject: Bluetooth: Reject connection with the device which has same BD_ADDR
+
+From: Lee, Chun-Yi <jlee@suse.com>
+
+commit 1ffc6f8cc33268731fcf9629fc4438f6db1191fc upstream.
+
+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. The paper mentioned that attacker can induce
+the attacked target to generate null link key (zero key) without PIN
+code. In BR/EDR, the key generation is actually handled in the controller
+which is below HCI.
+
+A condition of this attack is that attacker should change the
+BR_ADDR of his hacking device (Host B) to equal to the BR_ADDR with
+the target device being attacked (Host A).
+
+Thus, we reject the connection with device which has same BD_ADDR
+both on HCI_Create_Connection and HCI_Connection_Request to prevent
+the attack. A similar implementation also shows in btstack project.
+[3][4]
+
+Cc: stable@vger.kernel.org
+Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
+Link: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
+Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3523 [3]
+Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L7297 [4]
+Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_conn.c | 9 +++++++++
+ net/bluetooth/hci_event.c | 11 +++++++++++
+ 2 files changed, 20 insertions(+)
+
+--- a/net/bluetooth/hci_conn.c
++++ b/net/bluetooth/hci_conn.c
+@@ -1204,6 +1204,15 @@ struct hci_conn *hci_connect_acl(struct
+ return ERR_PTR(-EOPNOTSUPP);
+ }
+
++ /* Reject outgoing connection to device with same BD ADDR against
++ * CVE-2020-26555
++ */
++ if (!bacmp(&hdev->bdaddr, dst)) {
++ bt_dev_dbg(hdev, "Reject connection with same BD_ADDR %pMR\n",
++ dst);
++ return ERR_PTR(-ECONNREFUSED);
++ }
++
+ acl = hci_conn_hash_lookup_ba(hdev, ACL_LINK, dst);
+ if (!acl) {
+ acl = hci_conn_add(hdev, ACL_LINK, dst, HCI_ROLE_MASTER);
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -2510,6 +2510,17 @@ static void hci_conn_request_evt(struct
+ BT_DBG("%s bdaddr %pMR type 0x%x", hdev->name, &ev->bdaddr,
+ ev->link_type);
+
++ /* Reject incoming connection from device with same BD ADDR against
++ * CVE-2020-26555
++ */
++ if (!bacmp(&hdev->bdaddr, &ev->bdaddr))
++ {
++ bt_dev_dbg(hdev, "Reject connection with same BD_ADDR %pMR\n",
++ &ev->bdaddr);
++ hci_reject_conn(hdev, &ev->bdaddr);
++ return;
++ }
++
+ mask |= hci_proto_connect_ind(hdev, &ev->bdaddr, ev->link_type,
+ &flags);
+
--- /dev/null
+From 92d4abd66f7080075793970fc8f241239e58a9e7 Mon Sep 17 00:00:00 2001
+From: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
+Date: Wed, 20 Sep 2023 17:30:07 +0200
+Subject: Bluetooth: vhci: Fix race when opening vhci device
+
+From: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
+
+commit 92d4abd66f7080075793970fc8f241239e58a9e7 upstream.
+
+When the vhci device is opened in the two-step way, i.e.: open device
+then write a vendor packet with requested controller type, the device
+shall respond with a vendor packet which includes HCI index of created
+interface.
+
+When the virtual HCI is created, the host sends a reset request to the
+controller. This request is processed by the vhci_send_frame() function.
+However, this request is send by a different thread, so it might happen
+that this HCI request will be received before the vendor response is
+queued in the read queue. This results in the HCI vendor response and
+HCI reset request inversion in the read queue which leads to improper
+behavior of btvirt:
+
+> dmesg
+[1754256.640122] Bluetooth: MGMT ver 1.22
+[1754263.023806] Bluetooth: MGMT ver 1.22
+[1754265.043775] Bluetooth: hci1: Opcode 0x c03 failed: -110
+
+In order to synchronize vhci two-step open/setup process with virtual
+HCI initialization, this patch adds internal lock when queuing data in
+the vhci_send_frame() function.
+
+Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/hci_vhci.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/bluetooth/hci_vhci.c
++++ b/drivers/bluetooth/hci_vhci.c
+@@ -82,7 +82,10 @@ static int vhci_send_frame(struct hci_de
+ struct vhci_data *data = hci_get_drvdata(hdev);
+
+ memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
++
++ mutex_lock(&data->open_mutex);
+ skb_queue_tail(&data->readq, skb);
++ mutex_unlock(&data->open_mutex);
+
+ wake_up_interruptible(&data->read_wait);
+ return 0;
rpmsg-constify-local-variable-in-field-store-macro.patch
rpmsg-fix-kfree-of-static-memory-on-setting-driver_override.patch
usb-hub-guard-against-accesses-to-uninitialized-bos-descriptors.patch
+bluetooth-hci_event-ignore-null-link-key.patch
+bluetooth-reject-connection-with-the-device-which-has-same-bd_addr.patch
+bluetooth-fix-a-refcnt-underflow-problem-for-hci_conn.patch
+bluetooth-vhci-fix-race-when-opening-vhci-device.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
