From: Greg Kroah-Hartman Date: Mon, 24 Jun 2019 09:08:21 +0000 (+0800) Subject: 5.1-stable patches X-Git-Tag: v5.1.15~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2181cfaabcc1fe26c214d1701a2bc153dc335ea1;p=thirdparty%2Fkernel%2Fstable-queue.git 5.1-stable patches added patches: binder-fix-possible-uaf-when-freeing-buffer.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 fs-namespace-fix-unprivileged-mount-propagation.patch mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch mac80211-drop-robust-management-frames-from-unknown-ta.patch mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch nl-mac-80211-allow-4addr-ap-operation-on-crypto-controlled-devices.patch nl80211-fix-station_info-pertid-memory-leak.patch smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch staging-erofs-add-requirements-field-in-superblock.patch x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch --- diff --git a/queue-5.1/binder-fix-possible-uaf-when-freeing-buffer.patch b/queue-5.1/binder-fix-possible-uaf-when-freeing-buffer.patch new file mode 100644 index 00000000000..20466f774c2 --- /dev/null +++ b/queue-5.1/binder-fix-possible-uaf-when-freeing-buffer.patch @@ -0,0 +1,60 @@ +From a370003cc301d4361bae20c9ef615f89bf8d1e8a Mon Sep 17 00:00:00 2001 +From: Todd Kjos +Date: Wed, 12 Jun 2019 13:29:27 -0700 +Subject: binder: fix possible UAF when freeing buffer + +From: Todd Kjos + +commit a370003cc301d4361bae20c9ef615f89bf8d1e8a upstream. + +There is a race between the binder driver cleaning +up a completed transaction via binder_free_transaction() +and a user calling binder_ioctl(BC_FREE_BUFFER) to +release a buffer. It doesn't matter which is first but +they need to be protected against running concurrently +which can result in a UAF. + +Signed-off-by: Todd Kjos +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/android/binder.c | 16 ++++++++++++++-- + 1 file changed, 14 insertions(+), 2 deletions(-) + +--- a/drivers/android/binder.c ++++ b/drivers/android/binder.c +@@ -1950,8 +1950,18 @@ static void binder_free_txn_fixups(struc + + static void binder_free_transaction(struct binder_transaction *t) + { +- if (t->buffer) +- t->buffer->transaction = NULL; ++ struct binder_proc *target_proc = t->to_proc; ++ ++ if (target_proc) { ++ binder_inner_proc_lock(target_proc); ++ if (t->buffer) ++ t->buffer->transaction = NULL; ++ binder_inner_proc_unlock(target_proc); ++ } ++ /* ++ * If the transaction has no target_proc, then ++ * t->buffer->transaction has already been cleared. ++ */ + binder_free_txn_fixups(t); + kfree(t); + binder_stats_deleted(BINDER_STAT_TRANSACTION); +@@ -3550,10 +3560,12 @@ err_invalid_target_handle: + static void + binder_free_buf(struct binder_proc *proc, struct binder_buffer *buffer) + { ++ binder_inner_proc_lock(proc); + if (buffer->transaction) { + buffer->transaction->buffer = NULL; + buffer->transaction = NULL; + } ++ binder_inner_proc_unlock(proc); + if (buffer->async_transaction && buffer->target_node) { + struct binder_node *buf_node; + struct binder_work *w; diff --git a/queue-5.1/bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch b/queue-5.1/bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch new file mode 100644 index 00000000000..c7e5bf005b2 --- /dev/null +++ b/queue-5.1/bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch @@ -0,0 +1,52 @@ +From d5bb334a8e171b262e48f378bd2096c0ea458265 Mon Sep 17 00:00:00 2001 +From: Marcel Holtmann +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 + +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 +Signed-off-by: Johan Hedberg +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -190,6 +190,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 +@@ -1276,6 +1276,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; + } + diff --git a/queue-5.1/bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch b/queue-5.1/bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch new file mode 100644 index 00000000000..3fee91b0c35 --- /dev/null +++ b/queue-5.1/bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch @@ -0,0 +1,148 @@ +From 693cd8ce3f882524a5d06f7800dd8492411877b3 Mon Sep 17 00:00:00 2001 +From: Marcel Holtmann +Date: Sat, 22 Jun 2019 15:47:01 +0200 +Subject: Bluetooth: Fix regression with minimum encryption key size alignment + +From: Marcel Holtmann + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1276,14 +1276,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; + } + +@@ -1400,8 +1392,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 +@@ -1341,6 +1341,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; +@@ -1358,9 +1373,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) +@@ -1439,7 +1459,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; +@@ -7490,7 +7513,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); +@@ -7499,7 +7522,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; diff --git a/queue-5.1/cfg80211-fix-memory-leak-of-wiphy-device-name.patch b/queue-5.1/cfg80211-fix-memory-leak-of-wiphy-device-name.patch new file mode 100644 index 00000000000..35398d7038c --- /dev/null +++ b/queue-5.1/cfg80211-fix-memory-leak-of-wiphy-device-name.patch @@ -0,0 +1,35 @@ +From 4f488fbca2a86cc7714a128952eead92cac279ab Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 10 Jun 2019 13:02:19 -0700 +Subject: cfg80211: fix memory leak of wiphy device name + +From: Eric Biggers + +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 +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/wireless/core.c ++++ b/net/wireless/core.c +@@ -513,7 +513,7 @@ use_default_name: + &rdev->rfkill_ops, rdev); + + if (!rdev->rfkill) { +- kfree(rdev); ++ wiphy_free(&rdev->wiphy); + return NULL; + } + diff --git a/queue-5.1/fs-namespace-fix-unprivileged-mount-propagation.patch b/queue-5.1/fs-namespace-fix-unprivileged-mount-propagation.patch new file mode 100644 index 00000000000..f8210c25308 --- /dev/null +++ b/queue-5.1/fs-namespace-fix-unprivileged-mount-propagation.patch @@ -0,0 +1,72 @@ +From d728cf79164bb38e9628d15276e636539f857ef1 Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Mon, 17 Jun 2019 23:22:14 +0200 +Subject: fs/namespace: fix unprivileged mount propagation + +From: Christian Brauner + +commit d728cf79164bb38e9628d15276e636539f857ef1 upstream. + +When propagating mounts across mount namespaces owned by different user +namespaces it is not possible anymore to move or umount the mount in the +less privileged mount namespace. + +Here is a reproducer: + + sudo mount -t tmpfs tmpfs /mnt + sudo --make-rshared /mnt + + # create unprivileged user + mount namespace and preserve propagation + unshare -U -m --map-root --propagation=unchanged + + # now change back to the original mount namespace in another terminal: + sudo mkdir /mnt/aaa + sudo mount -t tmpfs tmpfs /mnt/aaa + + # now in the unprivileged user + mount namespace + mount --move /mnt/aaa /opt + +Unfortunately, this is a pretty big deal for userspace since this is +e.g. used to inject mounts into running unprivileged containers. +So this regression really needs to go away rather quickly. + +The problem is that a recent change falsely locked the root of the newly +added mounts by setting MNT_LOCKED. Fix this by only locking the mounts +on copy_mnt_ns() and not when adding a new mount. + +Fixes: 3bd045cc9c4b ("separate copying and locking mount tree on cross-userns copies") +Cc: Linus Torvalds +Cc: Al Viro +Cc: +Tested-by: Christian Brauner +Acked-by: Christian Brauner +Signed-off-by: "Eric W. Biederman" +Signed-off-by: Christian Brauner +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + fs/namespace.c | 1 + + fs/pnode.c | 1 - + 2 files changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -2079,6 +2079,7 @@ static int attach_recursive_mnt(struct m + /* Notice when we are propagating across user namespaces */ + if (child->mnt_parent->mnt_ns->user_ns != user_ns) + lock_mnt_tree(child); ++ child->mnt.mnt_flags &= ~MNT_LOCKED; + commit_tree(child); + } + put_mountpoint(smp); +--- a/fs/pnode.c ++++ b/fs/pnode.c +@@ -262,7 +262,6 @@ static int propagate_one(struct mount *m + child = copy_tree(last_source, last_source->mnt.mnt_root, type); + if (IS_ERR(child)) + return PTR_ERR(child); +- child->mnt.mnt_flags &= ~MNT_LOCKED; + mnt_set_mountpoint(m, mp, child); + last_dest = m; + last_source = child; diff --git a/queue-5.1/mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch b/queue-5.1/mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch new file mode 100644 index 00000000000..a64bc20ac74 --- /dev/null +++ b/queue-5.1/mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch @@ -0,0 +1,60 @@ +From a71fd9dac23613d96ba3c05619a8ef4fd6cdf9b9 Mon Sep 17 00:00:00 2001 +From: Jouni Malinen +Date: Tue, 28 May 2019 01:46:43 +0300 +Subject: mac80211: Do not use stack memory with scatterlist for GMAC + +From: Jouni Malinen + +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 +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/wpa.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/net/mac80211/wpa.c ++++ b/net/mac80211/wpa.c +@@ -1175,7 +1175,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)) +@@ -1206,13 +1206,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); diff --git a/queue-5.1/mac80211-drop-robust-management-frames-from-unknown-ta.patch b/queue-5.1/mac80211-drop-robust-management-frames-from-unknown-ta.patch new file mode 100644 index 00000000000..1710e66b0e2 --- /dev/null +++ b/queue-5.1/mac80211-drop-robust-management-frames-from-unknown-ta.patch @@ -0,0 +1,32 @@ +From 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 13 Feb 2019 15:13:30 +0100 +Subject: mac80211: drop robust management frames from unknown TA + +From: Johannes Berg + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/rx.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -3823,6 +3823,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); diff --git a/queue-5.1/mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch b/queue-5.1/mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch new file mode 100644 index 00000000000..5bc55bbc3e2 --- /dev/null +++ b/queue-5.1/mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch @@ -0,0 +1,117 @@ +From 79c92ca42b5a3e0ea172ea2ce8df8e125af237da Mon Sep 17 00:00:00 2001 +From: Yu Wang +Date: Fri, 10 May 2019 17:04:52 +0800 +Subject: mac80211: handle deauthentication/disassociation from TDLS peer + +From: Yu Wang + +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 +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -2222,6 +2222,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 +@@ -2963,7 +2963,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); +@@ -3028,6 +3028,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; +@@ -3077,6 +3082,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 +@@ -1994,3 +1994,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); ++} diff --git a/queue-5.1/nl-mac-80211-allow-4addr-ap-operation-on-crypto-controlled-devices.patch b/queue-5.1/nl-mac-80211-allow-4addr-ap-operation-on-crypto-controlled-devices.patch new file mode 100644 index 00000000000..32e18f0466d --- /dev/null +++ b/queue-5.1/nl-mac-80211-allow-4addr-ap-operation-on-crypto-controlled-devices.patch @@ -0,0 +1,108 @@ +From 33d915d9e8ce811d8958915ccd18d71a66c7c495 Mon Sep 17 00:00:00 2001 +From: Manikanta Pubbisetty +Date: Wed, 8 May 2019 14:55:33 +0530 +Subject: {nl,mac}80211: allow 4addr AP operation on crypto controlled devices + +From: Manikanta Pubbisetty + +commit 33d915d9e8ce811d8958915ccd18d71a66c7c495 upstream. + +As per the current design, in the case of sw crypto controlled devices, +it is the device which advertises the support for AP/VLAN iftype based +on it's ability to tranmsit packets encrypted in software +(In VLAN functionality, group traffic generated for a specific +VLAN group is always encrypted in software). Commit db3bdcb9c3ff +("mac80211: allow AP_VLAN operation on crypto controlled devices") +has introduced this change. + +Since 4addr AP operation also uses AP/VLAN iftype, this conditional +way of advertising AP/VLAN support has broken 4addr AP mode operation on +crypto controlled devices which do not support VLAN functionality. + +In the case of ath10k driver, not all firmwares have support for VLAN +functionality but all can support 4addr AP operation. Because AP/VLAN +support is not advertised for these devices, 4addr AP operations are +also blocked. + +Fix this by allowing 4addr operation on devices which do not support +AP/VLAN iftype but can support 4addr AP operation (decision is based on +the wiphy flag WIPHY_FLAG_4ADDR_AP). + +Cc: stable@vger.kernel.org +Fixes: db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") +Signed-off-by: Manikanta Pubbisetty +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + include/net/cfg80211.h | 3 ++- + net/mac80211/util.c | 4 +++- + net/wireless/core.c | 6 +++++- + net/wireless/nl80211.c | 8 ++++++-- + 4 files changed, 16 insertions(+), 5 deletions(-) + +--- a/include/net/cfg80211.h ++++ b/include/net/cfg80211.h +@@ -3767,7 +3767,8 @@ struct cfg80211_ops { + * on wiphy_new(), but can be changed by the driver if it has a good + * reason to override the default + * @WIPHY_FLAG_4ADDR_AP: supports 4addr mode even on AP (with a single station +- * on a VLAN interface) ++ * on a VLAN interface). This flag also serves an extra purpose of ++ * supporting 4ADDR AP mode on devices which do not support AP/VLAN iftype. + * @WIPHY_FLAG_4ADDR_STATION: supports 4addr mode even as a station + * @WIPHY_FLAG_CONTROL_PORT_PROTOCOL: This device supports setting the + * control port protocol ethertype. The device also honours the +--- a/net/mac80211/util.c ++++ b/net/mac80211/util.c +@@ -3757,7 +3757,9 @@ int ieee80211_check_combinations(struct + } + + /* Always allow software iftypes */ +- if (local->hw.wiphy->software_iftypes & BIT(iftype)) { ++ if (local->hw.wiphy->software_iftypes & BIT(iftype) || ++ (iftype == NL80211_IFTYPE_AP_VLAN && ++ local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) { + if (radar_detect) + return -EINVAL; + return 0; +--- a/net/wireless/core.c ++++ b/net/wireless/core.c +@@ -1396,8 +1396,12 @@ static int cfg80211_netdev_notifier_call + } + break; + case NETDEV_PRE_UP: +- if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) ++ if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) && ++ !(wdev->iftype == NL80211_IFTYPE_AP_VLAN && ++ rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP && ++ wdev->use_4addr)) + return notifier_from_errno(-EOPNOTSUPP); ++ + if (rfkill_blocked(rdev->rfkill)) + return notifier_from_errno(-ERFKILL); + break; +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -3385,8 +3385,7 @@ static int nl80211_new_interface(struct + if (info->attrs[NL80211_ATTR_IFTYPE]) + type = nla_get_u32(info->attrs[NL80211_ATTR_IFTYPE]); + +- if (!rdev->ops->add_virtual_intf || +- !(rdev->wiphy.interface_modes & (1 << type))) ++ if (!rdev->ops->add_virtual_intf) + return -EOPNOTSUPP; + + if ((type == NL80211_IFTYPE_P2P_DEVICE || type == NL80211_IFTYPE_NAN || +@@ -3405,6 +3404,11 @@ static int nl80211_new_interface(struct + return err; + } + ++ if (!(rdev->wiphy.interface_modes & (1 << type)) && ++ !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr && ++ rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP)) ++ return -EOPNOTSUPP; ++ + err = nl80211_parse_mon_options(rdev, type, info, ¶ms); + if (err < 0) + return err; diff --git a/queue-5.1/nl80211-fix-station_info-pertid-memory-leak.patch b/queue-5.1/nl80211-fix-station_info-pertid-memory-leak.patch new file mode 100644 index 00000000000..b53c6b32f83 --- /dev/null +++ b/queue-5.1/nl80211-fix-station_info-pertid-memory-leak.patch @@ -0,0 +1,39 @@ +From f77bf4863dc2218362f4227d56af4a5f3f08830c Mon Sep 17 00:00:00 2001 +From: Andy Strohman +Date: Fri, 24 May 2019 23:27:29 -0700 +Subject: nl80211: fix station_info pertid memory leak + +From: Andy Strohman + +commit f77bf4863dc2218362f4227d56af4a5f3f08830c upstream. + +When dumping stations, memory allocated for station_info's +pertid member will leak if the nl80211 header cannot be added to +the sk_buff due to insufficient tail room. + +I noticed this leak in the kmalloc-2048 cache. + +Cc: stable@vger.kernel.org +Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info") +Signed-off-by: Andy Strohman +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/nl80211.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -4804,8 +4804,10 @@ static int nl80211_send_station(struct s + struct nlattr *sinfoattr, *bss_param; + + hdr = nl80211hdr_put(msg, portid, seq, flags, cmd); +- if (!hdr) ++ if (!hdr) { ++ cfg80211_sinfo_release_content(sinfo); + return -1; ++ } + + if (nla_put_u32(msg, NL80211_ATTR_IFINDEX, dev->ifindex) || + nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr) || diff --git a/queue-5.1/series b/queue-5.1/series index de85aeb5764..608ada470bc 100644 --- a/queue-5.1/series +++ b/queue-5.1/series @@ -105,3 +105,16 @@ kvm-x86-mmu-allocate-pae-root-array-when-using-svm-s-32-bit-npt.patch ovl-make-i_ino-consistent-with-st_ino-in-more-cases.patch drm-vmwgfx-use-the-backdoor-port-if-the-hb-port-is-not-available.patch drm-i915-don-t-clobber-m-n-values-during-fastset-check.patch +binder-fix-possible-uaf-when-freeing-buffer.patch +staging-erofs-add-requirements-field-in-superblock.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 +x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch +fs-namespace-fix-unprivileged-mount-propagation.patch +cfg80211-fix-memory-leak-of-wiphy-device-name.patch +mac80211-drop-robust-management-frames-from-unknown-ta.patch +nl-mac-80211-allow-4addr-ap-operation-on-crypto-controlled-devices.patch +mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch +nl80211-fix-station_info-pertid-memory-leak.patch +mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch diff --git a/queue-5.1/smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch b/queue-5.1/smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch new file mode 100644 index 00000000000..b4dd58cd770 --- /dev/null +++ b/queue-5.1/smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch @@ -0,0 +1,37 @@ +From 8d526d62db907e786fd88948c75d1833d82bd80e Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Mon, 17 Jun 2019 14:49:07 -0500 +Subject: SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write + +From: Steve French + +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 +CC: Stable +Reviewed-by: Ronnie Sahlberg +Reviewed-by: Pavel Shilovsky +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/smb2maperror.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/cifs/smb2maperror.c ++++ b/fs/cifs/smb2maperror.c +@@ -457,7 +457,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"}, diff --git a/queue-5.1/staging-erofs-add-requirements-field-in-superblock.patch b/queue-5.1/staging-erofs-add-requirements-field-in-superblock.patch new file mode 100644 index 00000000000..61d6ae2a413 --- /dev/null +++ b/queue-5.1/staging-erofs-add-requirements-field-in-superblock.patch @@ -0,0 +1,106 @@ +From 5efe5137f05bbb4688890620934538c005e7d1d6 Mon Sep 17 00:00:00 2001 +From: Gao Xiang +Date: Thu, 13 Jun 2019 16:35:41 +0800 +Subject: staging: erofs: add requirements field in superblock + +From: Gao Xiang + +commit 5efe5137f05bbb4688890620934538c005e7d1d6 upstream. + +There are some backward incompatible features pending +for months, mainly due to on-disk format expensions. + +However, we should ensure that it cannot be mounted with +old kernels. Otherwise, it will causes unexpected behaviors. + +Fixes: ba2b77a82022 ("staging: erofs: add super block operations") +Cc: # 4.19+ +Reviewed-by: Chao Yu +Signed-off-by: Gao Xiang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/staging/erofs/erofs_fs.h | 13 ++++++++++--- + drivers/staging/erofs/internal.h | 2 ++ + drivers/staging/erofs/super.c | 19 +++++++++++++++++++ + 3 files changed, 31 insertions(+), 3 deletions(-) + +--- a/drivers/staging/erofs/erofs_fs.h ++++ b/drivers/staging/erofs/erofs_fs.h +@@ -17,10 +17,16 @@ + #define EROFS_SUPER_MAGIC_V1 0xE0F5E1E2 + #define EROFS_SUPER_OFFSET 1024 + ++/* ++ * Any bits that aren't in EROFS_ALL_REQUIREMENTS should be ++ * incompatible with this kernel version. ++ */ ++#define EROFS_ALL_REQUIREMENTS 0 ++ + struct erofs_super_block { + /* 0 */__le32 magic; /* in the little endian */ + /* 4 */__le32 checksum; /* crc32c(super_block) */ +-/* 8 */__le32 features; ++/* 8 */__le32 features; /* (aka. feature_compat) */ + /* 12 */__u8 blkszbits; /* support block_size == PAGE_SIZE only */ + /* 13 */__u8 reserved; + +@@ -34,9 +40,10 @@ struct erofs_super_block { + /* 44 */__le32 xattr_blkaddr; + /* 48 */__u8 uuid[16]; /* 128-bit uuid for volume */ + /* 64 */__u8 volume_name[16]; /* volume name */ ++/* 80 */__le32 requirements; /* (aka. feature_incompat) */ + +-/* 80 */__u8 reserved2[48]; /* 128 bytes */ +-} __packed; ++/* 84 */__u8 reserved2[44]; ++} __packed; /* 128 bytes */ + + /* + * erofs inode data mapping: +--- a/drivers/staging/erofs/internal.h ++++ b/drivers/staging/erofs/internal.h +@@ -114,6 +114,8 @@ struct erofs_sb_info { + + u8 uuid[16]; /* 128-bit uuid for volume */ + u8 volume_name[16]; /* volume name */ ++ u32 requirements; ++ + char *dev_name; + + unsigned int mount_opt; +--- a/drivers/staging/erofs/super.c ++++ b/drivers/staging/erofs/super.c +@@ -76,6 +76,22 @@ static void destroy_inode(struct inode * + call_rcu(&inode->i_rcu, i_callback); + } + ++static bool check_layout_compatibility(struct super_block *sb, ++ struct erofs_super_block *layout) ++{ ++ const unsigned int requirements = le32_to_cpu(layout->requirements); ++ ++ EROFS_SB(sb)->requirements = requirements; ++ ++ /* check if current kernel meets all mandatory requirements */ ++ if (requirements & (~EROFS_ALL_REQUIREMENTS)) { ++ errln("unidentified requirements %x, please upgrade kernel version", ++ requirements & ~EROFS_ALL_REQUIREMENTS); ++ return false; ++ } ++ return true; ++} ++ + static int superblock_read(struct super_block *sb) + { + struct erofs_sb_info *sbi; +@@ -109,6 +125,9 @@ static int superblock_read(struct super_ + goto out; + } + ++ if (!check_layout_compatibility(sb, layout)) ++ goto out; ++ + sbi->blocks = le32_to_cpu(layout->blocks); + sbi->meta_blkaddr = le32_to_cpu(layout->meta_blkaddr); + #ifdef CONFIG_EROFS_FS_XATTR diff --git a/queue-5.1/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch b/queue-5.1/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch new file mode 100644 index 00000000000..63e48b214d7 --- /dev/null +++ b/queue-5.1/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch @@ -0,0 +1,67 @@ +From ff17bbe0bb405ad8b36e55815d381841f9fdeebc Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Fri, 21 Jun 2019 08:43:04 -0700 +Subject: x86/vdso: Prevent segfaults due to hoisted vclock reads + +From: Andy Lutomirski + +commit ff17bbe0bb405ad8b36e55815d381841f9fdeebc upstream. + +GCC 5.5.0 sometimes cleverly hoists reads of the pvclock and/or hvclock +pages before the vclock mode checks. This creates a path through +vclock_gettime() in which no vclock is enabled at all (due to disabled +TSC on old CPUs, for example) but the pvclock or hvclock page +nevertheless read. This will segfault on bare metal. + +This fixes commit 459e3a21535a ("gcc-9: properly declare the +{pv,hv}clock_page storage") in the sense that, before that commit, GCC +didn't seem to generate the offending code. There was nothing wrong +with that commit per se, and -stable maintainers should backport this to +all supported kernels regardless of whether the offending commit was +present, since the same crash could just as easily be triggered by the +phase of the moon. + +On GCC 9.1.1, this doesn't seem to affect the generated code at all, so +I'm not too concerned about performance regressions from this fix. + +Cc: stable@vger.kernel.org +Cc: x86@kernel.org +Cc: Borislav Petkov +Reported-by: Duncan Roe +Signed-off-by: Andy Lutomirski +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/entry/vdso/vclock_gettime.c | 15 +++++++++++++-- + 1 file changed, 13 insertions(+), 2 deletions(-) + +--- a/arch/x86/entry/vdso/vclock_gettime.c ++++ b/arch/x86/entry/vdso/vclock_gettime.c +@@ -128,13 +128,24 @@ notrace static inline u64 vgetcyc(int mo + { + if (mode == VCLOCK_TSC) + return (u64)rdtsc_ordered(); ++ ++ /* ++ * For any memory-mapped vclock type, we need to make sure that gcc ++ * doesn't cleverly hoist a load before the mode check. Otherwise we ++ * might end up touching the memory-mapped page even if the vclock in ++ * question isn't enabled, which will segfault. Hence the barriers. ++ */ + #ifdef CONFIG_PARAVIRT_CLOCK +- else if (mode == VCLOCK_PVCLOCK) ++ if (mode == VCLOCK_PVCLOCK) { ++ barrier(); + return vread_pvclock(); ++ } + #endif + #ifdef CONFIG_HYPERV_TSCPAGE +- else if (mode == VCLOCK_HVCLOCK) ++ if (mode == VCLOCK_HVCLOCK) { ++ barrier(); + return vread_hvclock(); ++ } + #endif + return U64_MAX; + }