--- /dev/null
+From a370003cc301d4361bae20c9ef615f89bf8d1e8a Mon Sep 17 00:00:00 2001
+From: Todd Kjos <tkjos@android.com>
+Date: Wed, 12 Jun 2019 13:29:27 -0700
+Subject: binder: fix possible UAF when freeing buffer
+
+From: Todd Kjos <tkjos@android.com>
+
+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 <tkjos@google.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /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
+@@ -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;
+ }
+
--- /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
+@@ -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;
--- /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
+@@ -513,7 +513,7 @@ use_default_name:
+ &rdev->rfkill_ops, rdev);
+
+ if (!rdev->rfkill) {
+- kfree(rdev);
++ wiphy_free(&rdev->wiphy);
+ return NULL;
+ }
+
--- /dev/null
+From d728cf79164bb38e9628d15276e636539f857ef1 Mon Sep 17 00:00:00 2001
+From: Christian Brauner <christian@brauner.io>
+Date: Mon, 17 Jun 2019 23:22:14 +0200
+Subject: fs/namespace: fix unprivileged mount propagation
+
+From: Christian Brauner <christian@brauner.io>
+
+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 <torvalds@linux-foundation.org>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: <stable@vger.kernel.org>
+Tested-by: Christian Brauner <christian@brauner.io>
+Acked-by: Christian Brauner <christian@brauner.io>
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Christian Brauner <christian@brauner.io>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /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
+@@ -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);
--- /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
+@@ -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);
--- /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
+@@ -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);
++}
--- /dev/null
+From 33d915d9e8ce811d8958915ccd18d71a66c7c495 Mon Sep 17 00:00:00 2001
+From: Manikanta Pubbisetty <mpubbise@codeaurora.org>
+Date: Wed, 8 May 2019 14:55:33 +0530
+Subject: {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
+
+From: Manikanta Pubbisetty <mpubbise@codeaurora.org>
+
+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 <mpubbise@codeaurora.org>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From f77bf4863dc2218362f4227d56af4a5f3f08830c Mon Sep 17 00:00:00 2001
+From: Andy Strohman <andrew@andrewstrohman.com>
+Date: Fri, 24 May 2019 23:27:29 -0700
+Subject: nl80211: fix station_info pertid memory leak
+
+From: Andy Strohman <andrew@andrewstrohman.com>
+
+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 <andy@uplevelsystems.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) ||
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
--- /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
+@@ -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"},
--- /dev/null
+From 5efe5137f05bbb4688890620934538c005e7d1d6 Mon Sep 17 00:00:00 2001
+From: Gao Xiang <gaoxiang25@huawei.com>
+Date: Thu, 13 Jun 2019 16:35:41 +0800
+Subject: staging: erofs: add requirements field in superblock
+
+From: Gao Xiang <gaoxiang25@huawei.com>
+
+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: <stable@vger.kernel.org> # 4.19+
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From ff17bbe0bb405ad8b36e55815d381841f9fdeebc Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Fri, 21 Jun 2019 08:43:04 -0700
+Subject: x86/vdso: Prevent segfaults due to hoisted vclock reads
+
+From: Andy Lutomirski <luto@kernel.org>
+
+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 <bp@alien8.de>
+Reported-by: Duncan Roe <duncan_roe@optusnet.com.au>
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
