--- /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
+@@ -174,6 +174,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
+@@ -1177,6 +1177,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
+@@ -1177,14 +1177,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;
+ }
+
+@@ -1301,8 +1293,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
+@@ -1329,6 +1329,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;
+@@ -1346,9 +1361,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)
+@@ -1427,7 +1447,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;
+@@ -7432,7 +7455,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);
+@@ -7441,7 +7464,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
+@@ -447,7 +447,7 @@ use_default_name:
+ &rdev->rfkill_ops, rdev);
+
+ if (!rdev->rfkill) {
+- kfree(rdev);
++ wiphy_free(&rdev->wiphy);
+ return NULL;
+ }
+
--- /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
+@@ -3324,6 +3324,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-flexcan-fix-timeout-when-set-small-bitrate.patch
can-purge-socket-error-queue-on-sock-destruct.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
+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
--- /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
+@@ -455,7 +455,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
