From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Mon, 23 Oct 2023 09:33:34 +0000 (+0200)
Subject: 4.14-stable patches
X-Git-Tag: v4.14.328~9
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a42c04dbc9d99bc8252e9bb3b7e5b8cfb23e957e;p=thirdparty%2Fkernel%2Fstable-queue.git

4.14-stable patches

added patches:
	bluetooth-hci_event-fix-using-memcmp-when-comparing-keys.patch
---

diff --git a/queue-4.14/bluetooth-hci_event-fix-using-memcmp-when-comparing-keys.patch b/queue-4.14/bluetooth-hci_event-fix-using-memcmp-when-comparing-keys.patch
new file mode 100644
index 00000000000..d85dc64c64a
--- /dev/null
+++ b/queue-4.14/bluetooth-hci_event-fix-using-memcmp-when-comparing-keys.patch
@@ -0,0 +1,69 @@
+From b541260615f601ae1b5d6d0cc54e790de706303b Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Thu, 5 Oct 2023 13:59:59 -0700
+Subject: Bluetooth: hci_event: Fix using memcmp when comparing keys
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit b541260615f601ae1b5d6d0cc54e790de706303b upstream.
+
+memcmp is not consider safe to use with cryptographic secrets:
+
+ 'Do  not  use memcmp() to compare security critical data, such as
+ cryptographic secrets, because the required CPU time depends on the
+ number of equal bytes.'
+
+While usage of memcmp for ZERO_KEY may not be considered a security
+critical data, it can lead to more usage of memcmp with pairing keys
+which could introduce more security problems.
+
+Fixes: 455c2ff0a558 ("Bluetooth: Fix BR/EDR out-of-band pairing with only initiator data")
+Fixes: 33155c4aae52 ("Bluetooth: hci_event: Ignore NULL link key")
+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 |   12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -25,6 +25,8 @@
+ /* Bluetooth HCI event handling. */
+ 
+ #include <asm/unaligned.h>
++#include <linux/crypto.h>
++#include <crypto/algapi.h>
+ 
+ #include <net/bluetooth/bluetooth.h>
+ #include <net/bluetooth/hci_core.h>
+@@ -3505,7 +3507,7 @@ static void hci_link_key_notify_evt(stru
+ 		goto unlock;
+ 
+ 	/* Ignore NULL link key against CVE-2020-26555 */
+-	if (!memcmp(ev->link_key, ZERO_KEY, HCI_LINK_KEY_SIZE)) {
++	if (!crypto_memneq(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);
+@@ -3991,8 +3993,8 @@ static u8 bredr_oob_data_present(struct
+ 		 * available, then do not declare that OOB data is
+ 		 * present.
+ 		 */
+-		if (!memcmp(data->rand256, ZERO_KEY, 16) ||
+-		    !memcmp(data->hash256, ZERO_KEY, 16))
++		if (!crypto_memneq(data->rand256, ZERO_KEY, 16) ||
++		    !crypto_memneq(data->hash256, ZERO_KEY, 16))
+ 			return 0x00;
+ 
+ 		return 0x02;
+@@ -4002,8 +4004,8 @@ static u8 bredr_oob_data_present(struct
+ 	 * not supported by the hardware, then check that if
+ 	 * P-192 data values are present.
+ 	 */
+-	if (!memcmp(data->rand192, ZERO_KEY, 16) ||
+-	    !memcmp(data->hash192, ZERO_KEY, 16))
++	if (!crypto_memneq(data->rand192, ZERO_KEY, 16) ||
++	    !crypto_memneq(data->hash192, ZERO_KEY, 16))
+ 		return 0x00;
+ 
+ 	return 0x01;
diff --git a/queue-4.14/series b/queue-4.14/series
index 81ac4b3226e..06a8fc7973f 100644
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -63,3 +63,4 @@ s390-pci-fix-iommu-bitmap-allocation.patch
 gpio-vf610-set-value-before-the-direction-to-avoid-a-glitch.patch
 bluetooth-hci_sock-fix-slab-oob-read-in-create_monitor_event.patch
 bluetooth-hci_sock-correctly-bounds-check-and-pad-hci_mon_new_index-name.patch
+bluetooth-hci_event-fix-using-memcmp-when-comparing-keys.patch