--- /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
+@@ -178,6 +178,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;
+@@ -7455,7 +7478,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);
+@@ -7464,7 +7487,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
+@@ -498,7 +498,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
+@@ -3589,6 +3589,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);
--- /dev/null
+From 79c92ca42b5a3e0ea172ea2ce8df8e125af237da Mon Sep 17 00:00:00 2001
+From: Yu Wang <yyuwang@codeaurora.org>
+Date: Fri, 10 May 2019 17:04:52 +0800
+Subject: mac80211: handle deauthentication/disassociation from TDLS peer
+
+From: Yu Wang <yyuwang@codeaurora.org>
+
+commit 79c92ca42b5a3e0ea172ea2ce8df8e125af237da upstream.
+
+When receiving a deauthentication/disassociation frame from a TDLS
+peer, a station should not disconnect the current AP, but only
+disable the current TDLS link if it's enabled.
+
+Without this change, a TDLS issue can be reproduced by following the
+steps as below:
+
+1. STA-1 and STA-2 are connected to AP, bidirection traffic is running
+ between STA-1 and STA-2.
+2. Set up TDLS link between STA-1 and STA-2, stay for a while, then
+ teardown TDLS link.
+3. Repeat step #2 and monitor the connection between STA and AP.
+
+During the test, one STA may send a deauthentication/disassociation
+frame to another, after TDLS teardown, with reason code 6/7, which
+means: Class 2/3 frame received from nonassociated STA.
+
+On receive this frame, the receiver STA will disconnect the current
+AP and then reconnect. It's not a expected behavior, purpose of this
+frame should be disabling the TDLS link, not the link with AP.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Yu Wang <yyuwang@codeaurora.org>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/ieee80211_i.h | 3 +++
+ net/mac80211/mlme.c | 12 +++++++++++-
+ net/mac80211/tdls.c | 23 +++++++++++++++++++++++
+ 3 files changed, 37 insertions(+), 1 deletion(-)
+
+--- a/net/mac80211/ieee80211_i.h
++++ b/net/mac80211/ieee80211_i.h
+@@ -2150,6 +2150,9 @@ void ieee80211_tdls_cancel_channel_switc
+ const u8 *addr);
+ void ieee80211_teardown_tdls_peers(struct ieee80211_sub_if_data *sdata);
+ void ieee80211_tdls_chsw_work(struct work_struct *wk);
++void ieee80211_tdls_handle_disconnect(struct ieee80211_sub_if_data *sdata,
++ const u8 *peer, u16 reason);
++const char *ieee80211_get_reason_code_string(u16 reason_code);
+
+ extern const struct ethtool_ops ieee80211_ethtool_ops;
+
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -2744,7 +2744,7 @@ static void ieee80211_rx_mgmt_auth(struc
+ #define case_WLAN(type) \
+ case WLAN_REASON_##type: return #type
+
+-static const char *ieee80211_get_reason_code_string(u16 reason_code)
++const char *ieee80211_get_reason_code_string(u16 reason_code)
+ {
+ switch (reason_code) {
+ case_WLAN(UNSPECIFIED);
+@@ -2809,6 +2809,11 @@ static void ieee80211_rx_mgmt_deauth(str
+ if (len < 24 + 2)
+ return;
+
++ if (!ether_addr_equal(mgmt->bssid, mgmt->sa)) {
++ ieee80211_tdls_handle_disconnect(sdata, mgmt->sa, reason_code);
++ return;
++ }
++
+ if (ifmgd->associated &&
+ ether_addr_equal(mgmt->bssid, ifmgd->associated->bssid)) {
+ const u8 *bssid = ifmgd->associated->bssid;
+@@ -2858,6 +2863,11 @@ static void ieee80211_rx_mgmt_disassoc(s
+
+ reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
+
++ if (!ether_addr_equal(mgmt->bssid, mgmt->sa)) {
++ ieee80211_tdls_handle_disconnect(sdata, mgmt->sa, reason_code);
++ return;
++ }
++
+ sdata_info(sdata, "disassociated from %pM (Reason: %u=%s)\n",
+ mgmt->sa, reason_code,
+ ieee80211_get_reason_code_string(reason_code));
+--- a/net/mac80211/tdls.c
++++ b/net/mac80211/tdls.c
+@@ -1988,3 +1988,26 @@ void ieee80211_tdls_chsw_work(struct wor
+ }
+ rtnl_unlock();
+ }
++
++void ieee80211_tdls_handle_disconnect(struct ieee80211_sub_if_data *sdata,
++ const u8 *peer, u16 reason)
++{
++ struct ieee80211_sta *sta;
++
++ rcu_read_lock();
++ sta = ieee80211_find_sta(&sdata->vif, peer);
++ if (!sta || !sta->tdls) {
++ rcu_read_unlock();
++ return;
++ }
++ rcu_read_unlock();
++
++ tdls_dbg(sdata, "disconnected from TDLS peer %pM (Reason: %u=%s)\n",
++ peer, reason,
++ ieee80211_get_reason_code_string(reason));
++
++ ieee80211_tdls_oper_request(&sdata->vif, peer,
++ NL80211_TDLS_TEARDOWN,
++ WLAN_REASON_TDLS_TEARDOWN_UNREACHABLE,
++ GFP_ATOMIC);
++}
powerpc-bpf-use-unsigned-division-instruction-for-64-bit-operations.patch
arm-imx-cpuidle-imx6sx-restrict-the-sw2iso-increase-to-i.mx6sx.patch
arm-dts-am57xx-idk-remove-support-for-voltage-switching-for-sd-card.patch
+bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch
+bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch
+smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch
+cfg80211-fix-memory-leak-of-wiphy-device-name.patch
+mac80211-drop-robust-management-frames-from-unknown-ta.patch
+mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch
+mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch
--- /dev/null
+From 8d526d62db907e786fd88948c75d1833d82bd80e Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Mon, 17 Jun 2019 14:49:07 -0500
+Subject: SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 8d526d62db907e786fd88948c75d1833d82bd80e upstream.
+
+Some servers such as Windows 10 will return STATUS_INSUFFICIENT_RESOURCES
+as the number of simultaneous SMB3 requests grows (even though the client
+has sufficient credits). Return EAGAIN on STATUS_INSUFFICIENT_RESOURCES
+so that we can retry writes which fail with this status code.
+
+This (for example) fixes large file copies to Windows 10 on fast networks.
+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2maperror.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/smb2maperror.c
++++ b/fs/cifs/smb2maperror.c
+@@ -456,7 +456,7 @@ static const struct status_to_posix_erro
+ {STATUS_FILE_INVALID, -EIO, "STATUS_FILE_INVALID"},
+ {STATUS_ALLOTTED_SPACE_EXCEEDED, -EIO,
+ "STATUS_ALLOTTED_SPACE_EXCEEDED"},
+- {STATUS_INSUFFICIENT_RESOURCES, -EREMOTEIO,
++ {STATUS_INSUFFICIENT_RESOURCES, -EAGAIN,
+ "STATUS_INSUFFICIENT_RESOURCES"},
+ {STATUS_DFS_EXIT_PATH_FOUND, -EIO, "STATUS_DFS_EXIT_PATH_FOUND"},
+ {STATUS_DEVICE_DATA_ERROR, -EIO, "STATUS_DEVICE_DATA_ERROR"},
projects / thirdparty / kernel / stable-queue.git / commitdiff
