--- /dev/null
+From d5bb334a8e171b262e48f378bd2096c0ea458265 Mon Sep 17 00:00:00 2001
+From: Marcel Holtmann <marcel@holtmann.org>
+Date: Wed, 24 Apr 2019 22:19:17 +0200
+Subject: Bluetooth: Align minimum encryption key size for LE and BR/EDR connections
+
+From: Marcel Holtmann <marcel@holtmann.org>
+
+commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
+
+The minimum encryption key size for LE connections is 56 bits and to
+align LE with BR/EDR, enforce 56 bits of minimum encryption key size for
+BR/EDR connections as well.
+
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/net/bluetooth/hci_core.h | 3 +++
+ net/bluetooth/hci_conn.c | 8 ++++++++
+ 2 files changed, 11 insertions(+)
+
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -176,6 +176,9 @@ struct adv_info {
+
+ #define HCI_MAX_SHORT_NAME_LENGTH 10
+
++/* Min encryption key size to match with SMP */
++#define HCI_MIN_ENC_KEY_SIZE 7
++
+ /* Default LE RPA expiry time, 15 minutes */
+ #define HCI_DEFAULT_RPA_TIMEOUT (15 * 60)
+
+--- a/net/bluetooth/hci_conn.c
++++ b/net/bluetooth/hci_conn.c
+@@ -1165,6 +1165,14 @@ int hci_conn_check_link_mode(struct hci_
+ !test_bit(HCI_CONN_ENCRYPT, &conn->flags))
+ return 0;
+
++ /* The minimum encryption key size needs to be enforced by the
++ * host stack before establishing any L2CAP connections. The
++ * specification in theory allows a minimum of 1, but to align
++ * BR/EDR and LE transports, a minimum of 7 is chosen.
++ */
++ if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
++ return 0;
++
+ return 1;
+ }
+
--- /dev/null
+From 693cd8ce3f882524a5d06f7800dd8492411877b3 Mon Sep 17 00:00:00 2001
+From: Marcel Holtmann <marcel@holtmann.org>
+Date: Sat, 22 Jun 2019 15:47:01 +0200
+Subject: Bluetooth: Fix regression with minimum encryption key size alignment
+
+From: Marcel Holtmann <marcel@holtmann.org>
+
+commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream.
+
+When trying to align the minimum encryption key size requirement for
+Bluetooth connections, it turns out doing this in a central location in
+the HCI connection handling code is not possible.
+
+Original Bluetooth version up to 2.0 used a security model where the
+L2CAP service would enforce authentication and encryption. Starting
+with Bluetooth 2.1 and Secure Simple Pairing that model has changed into
+that the connection initiator is responsible for providing an encrypted
+ACL link before any L2CAP communication can happen.
+
+Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and
+before devices are causing a regression. The encryption key size check
+needs to be moved out of the HCI connection handling into the L2CAP
+channel setup.
+
+To achieve this, the current check inside hci_conn_security() has been
+moved into l2cap_check_enc_key_size() helper function and then called
+from four decisions point inside L2CAP to cover all combinations of
+Secure Simple Pairing enabled devices and device using legacy pairing
+and legacy service security model.
+
+Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/hci_conn.c | 18 +++++++++---------
+ net/bluetooth/l2cap_core.c | 33 ++++++++++++++++++++++++++++-----
+ 2 files changed, 37 insertions(+), 14 deletions(-)
+
+--- a/net/bluetooth/hci_conn.c
++++ b/net/bluetooth/hci_conn.c
+@@ -1165,14 +1165,6 @@ int hci_conn_check_link_mode(struct hci_
+ !test_bit(HCI_CONN_ENCRYPT, &conn->flags))
+ return 0;
+
+- /* The minimum encryption key size needs to be enforced by the
+- * host stack before establishing any L2CAP connections. The
+- * specification in theory allows a minimum of 1, but to align
+- * BR/EDR and LE transports, a minimum of 7 is chosen.
+- */
+- if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
+- return 0;
+-
+ return 1;
+ }
+
+@@ -1289,8 +1281,16 @@ auth:
+ return 0;
+
+ encrypt:
+- if (test_bit(HCI_CONN_ENCRYPT, &conn->flags))
++ if (test_bit(HCI_CONN_ENCRYPT, &conn->flags)) {
++ /* Ensure that the encryption key size has been read,
++ * otherwise stall the upper layer responses.
++ */
++ if (!conn->enc_key_size)
++ return 0;
++
++ /* Nothing else needed, all requirements are met */
+ return 1;
++ }
+
+ hci_conn_encrypt(conn);
+ return 0;
+--- a/net/bluetooth/l2cap_core.c
++++ b/net/bluetooth/l2cap_core.c
+@@ -1340,6 +1340,21 @@ static void l2cap_request_info(struct l2
+ sizeof(req), &req);
+ }
+
++static bool l2cap_check_enc_key_size(struct hci_conn *hcon)
++{
++ /* The minimum encryption key size needs to be enforced by the
++ * host stack before establishing any L2CAP connections. The
++ * specification in theory allows a minimum of 1, but to align
++ * BR/EDR and LE transports, a minimum of 7 is chosen.
++ *
++ * This check might also be called for unencrypted connections
++ * that have no key size requirements. Ensure that the link is
++ * actually encrypted before enforcing a key size.
++ */
++ return (!test_bit(HCI_CONN_ENCRYPT, &hcon->flags) ||
++ hcon->enc_key_size > HCI_MIN_ENC_KEY_SIZE);
++}
++
+ static void l2cap_do_start(struct l2cap_chan *chan)
+ {
+ struct l2cap_conn *conn = chan->conn;
+@@ -1357,9 +1372,14 @@ static void l2cap_do_start(struct l2cap_
+ if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
+ return;
+
+- if (l2cap_chan_check_security(chan, true) &&
+- __l2cap_no_conn_pending(chan))
++ if (!l2cap_chan_check_security(chan, true) ||
++ !__l2cap_no_conn_pending(chan))
++ return;
++
++ if (l2cap_check_enc_key_size(conn->hcon))
+ l2cap_start_connection(chan);
++ else
++ __set_chan_timer(chan, L2CAP_DISC_TIMEOUT);
+ }
+
+ static inline int l2cap_mode_supported(__u8 mode, __u32 feat_mask)
+@@ -1438,7 +1458,10 @@ static void l2cap_conn_start(struct l2ca
+ continue;
+ }
+
+- l2cap_start_connection(chan);
++ if (l2cap_check_enc_key_size(conn->hcon))
++ l2cap_start_connection(chan);
++ else
++ l2cap_chan_close(chan, ECONNREFUSED);
+
+ } else if (chan->state == BT_CONNECT2) {
+ struct l2cap_conn_rsp rsp;
+@@ -7447,7 +7470,7 @@ static void l2cap_security_cfm(struct hc
+ }
+
+ if (chan->state == BT_CONNECT) {
+- if (!status)
++ if (!status && l2cap_check_enc_key_size(hcon))
+ l2cap_start_connection(chan);
+ else
+ __set_chan_timer(chan, L2CAP_DISC_TIMEOUT);
+@@ -7456,7 +7479,7 @@ static void l2cap_security_cfm(struct hc
+ struct l2cap_conn_rsp rsp;
+ __u16 res, stat;
+
+- if (!status) {
++ if (!status && l2cap_check_enc_key_size(hcon)) {
+ if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) {
+ res = L2CAP_CR_PEND;
+ stat = L2CAP_CS_AUTHOR_PEND;
--- /dev/null
+From 4f488fbca2a86cc7714a128952eead92cac279ab Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Mon, 10 Jun 2019 13:02:19 -0700
+Subject: cfg80211: fix memory leak of wiphy device name
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 4f488fbca2a86cc7714a128952eead92cac279ab upstream.
+
+In wiphy_new_nm(), if an error occurs after dev_set_name() and
+device_initialize() have already been called, it's necessary to call
+put_device() (via wiphy_free()) to avoid a memory leak.
+
+Reported-by: syzbot+7fddca22578bc67c3fe4@syzkaller.appspotmail.com
+Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/wireless/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/wireless/core.c
++++ b/net/wireless/core.c
+@@ -478,7 +478,7 @@ use_default_name:
+ &rdev->rfkill_ops, rdev);
+
+ if (!rdev->rfkill) {
+- kfree(rdev);
++ wiphy_free(&rdev->wiphy);
+ return NULL;
+ }
+
--- /dev/null
+From a71fd9dac23613d96ba3c05619a8ef4fd6cdf9b9 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j@w1.fi>
+Date: Tue, 28 May 2019 01:46:43 +0300
+Subject: mac80211: Do not use stack memory with scatterlist for GMAC
+
+From: Jouni Malinen <j@w1.fi>
+
+commit a71fd9dac23613d96ba3c05619a8ef4fd6cdf9b9 upstream.
+
+ieee80211_aes_gmac() uses the mic argument directly in sg_set_buf() and
+that does not allow use of stack memory (e.g., BUG_ON() is hit in
+sg_set_buf() with CONFIG_DEBUG_SG). BIP GMAC TX side is fine for this
+since it can use the skb data buffer, but the RX side was using a stack
+variable for deriving the local MIC value to compare against the
+received one.
+
+Fix this by allocating heap memory for the mic buffer.
+
+This was found with hwsim test case ap_cipher_bip_gmac_128 hitting that
+BUG_ON() and kernel panic.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jouni Malinen <j@w1.fi>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/wpa.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/net/mac80211/wpa.c
++++ b/net/mac80211/wpa.c
+@@ -1169,7 +1169,7 @@ ieee80211_crypto_aes_gmac_decrypt(struct
+ struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
+ struct ieee80211_key *key = rx->key;
+ struct ieee80211_mmie_16 *mmie;
+- u8 aad[GMAC_AAD_LEN], mic[GMAC_MIC_LEN], ipn[6], nonce[GMAC_NONCE_LEN];
++ u8 aad[GMAC_AAD_LEN], *mic, ipn[6], nonce[GMAC_NONCE_LEN];
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+
+ if (!ieee80211_is_mgmt(hdr->frame_control))
+@@ -1200,13 +1200,18 @@ ieee80211_crypto_aes_gmac_decrypt(struct
+ memcpy(nonce, hdr->addr2, ETH_ALEN);
+ memcpy(nonce + ETH_ALEN, ipn, 6);
+
++ mic = kmalloc(GMAC_MIC_LEN, GFP_ATOMIC);
++ if (!mic)
++ return RX_DROP_UNUSABLE;
+ if (ieee80211_aes_gmac(key->u.aes_gmac.tfm, aad, nonce,
+ skb->data + 24, skb->len - 24,
+ mic) < 0 ||
+ crypto_memneq(mic, mmie->mic, sizeof(mmie->mic))) {
+ key->u.aes_gmac.icverrors++;
++ kfree(mic);
+ return RX_DROP_UNUSABLE;
+ }
++ kfree(mic);
+ }
+
+ memcpy(key->u.aes_gmac.rx_pn, ipn, 6);
--- /dev/null
+From 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 13 Feb 2019 15:13:30 +0100
+Subject: mac80211: drop robust management frames from unknown TA
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream.
+
+When receiving a robust management frame, drop it if we don't have
+rx->sta since then we don't have a security association and thus
+couldn't possibly validate the frame.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/rx.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/mac80211/rx.c
++++ b/net/mac80211/rx.c
+@@ -3568,6 +3568,8 @@ static bool ieee80211_accept_frame(struc
+ case NL80211_IFTYPE_STATION:
+ if (!bssid && !sdata->u.mgd.use_4addr)
+ return false;
++ if (ieee80211_is_robust_mgmt_frame(skb) && !rx->sta)
++ return false;
+ if (multicast)
+ return true;
+ return ether_addr_equal(sdata->vif.addr, hdr->addr1);
can-purge-socket-error-queue-on-sock-destruct.patch
powerpc-bpf-use-unsigned-division-instruction-for-64-bit-operations.patch
arm-imx-cpuidle-imx6sx-restrict-the-sw2iso-increase-to-i.mx6sx.patch
+bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch
+bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch
+cfg80211-fix-memory-leak-of-wiphy-device-name.patch
+mac80211-drop-robust-management-frames-from-unknown-ta.patch
+mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
