--- /dev/null
+From 338f977f4eb441e69bb9a46eaa0ac715c931a67f Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Sat, 1 Feb 2014 00:16:23 +0100
+Subject: mac80211: fix fragmentation code, particularly for encryption
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f upstream.
+
+The "new" fragmentation code (since my rewrite almost 5 years ago)
+erroneously sets skb->len rather than using skb_trim() to adjust
+the length of the first fragment after copying out all the others.
+This leaves the skb tail pointer pointing to after where the data
+originally ended, and thus causes the encryption MIC to be written
+at that point, rather than where it belongs: immediately after the
+data.
+
+The impact of this is that if software encryption is done, then
+ a) encryption doesn't work for the first fragment, the connection
+ becomes unusable as the first fragment will never be properly
+ verified at the receiver, the MIC is practically guaranteed to
+ be wrong
+ b) we leak up to 8 bytes of plaintext (!) of the packet out into
+ the air
+
+This is only mitigated by the fact that many devices are capable
+of doing encryption in hardware, in which case this can't happen
+as the tail pointer is irrelevant in that case. Additionally,
+fragmentation is not used very frequently and would normally have
+to be configured manually.
+
+Fix this by using skb_trim() properly.
+
+Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
+Reported-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/tx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/tx.c
++++ b/net/mac80211/tx.c
+@@ -874,7 +874,7 @@ static int ieee80211_fragment(struct iee
+ }
+
+ /* adjust first fragment's length */
+- skb->len = hdrlen + per_fragm;
++ skb_trim(skb, hdrlen + per_fragm);
+ return 0;
+ }
+
--- /dev/null
+From d4c80d9df6d1e4473b1409e4d220ca3d1612125c Mon Sep 17 00:00:00 2001
+From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Thu, 30 Jan 2014 14:17:28 +0530
+Subject: mac80211: Fix IBSS disconnect
+
+From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit d4c80d9df6d1e4473b1409e4d220ca3d1612125c upstream.
+
+Currently, when a station leaves an IBSS network, the
+corresponding BSS is not dropped from cfg80211 if there are
+other active stations in the network. But, the small
+window that is present when trying to determine a station's
+status based on IEEE80211_IBSS_MERGE_INTERVAL introduces
+a race.
+
+Instead of trying to keep the BSS, always remove it when
+leaving an IBSS network. There is not much benefit to retain
+the BSS entry since it will be added with a subsequent join
+operation.
+
+This fixes an issue where a dangling BSS entry causes ath9k
+to wait for a beacon indefinitely.
+
+Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/ibss.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/net/mac80211/ibss.c
++++ b/net/mac80211/ibss.c
+@@ -687,12 +687,9 @@ static void ieee80211_ibss_disconnect(st
+ struct cfg80211_bss *cbss;
+ struct beacon_data *presp;
+ struct sta_info *sta;
+- int active_ibss;
+ u16 capability;
+
+- active_ibss = ieee80211_sta_active_ibss(sdata);
+-
+- if (!active_ibss && !is_zero_ether_addr(ifibss->bssid)) {
++ if (!is_zero_ether_addr(ifibss->bssid)) {
+ capability = WLAN_CAPABILITY_IBSS;
+
+ if (ifibss->privacy)
--- /dev/null
+From 2f617435c3a6fe3f39efb9ae2baa77de2d6c97b8 Mon Sep 17 00:00:00 2001
+From: Eliad Peller <eliad@wizery.com>
+Date: Sun, 12 Jan 2014 11:06:37 +0200
+Subject: mac80211: move roc cookie assignment earlier
+
+From: Eliad Peller <eliad@wizery.com>
+
+commit 2f617435c3a6fe3f39efb9ae2baa77de2d6c97b8 upstream.
+
+ieee80211_start_roc_work() might add a new roc
+to existing roc, and tell cfg80211 it has already
+started.
+
+However, this might happen before the roc cookie
+was set, resulting in REMAIN_ON_CHANNEL (started)
+event with null cookie. Consequently, it can make
+wpa_supplicant go out of sync.
+
+Fix it by setting the roc cookie earlier.
+
+Signed-off-by: Eliad Peller <eliad@wizery.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/cfg.c | 36 ++++++++++++++++++------------------
+ 1 file changed, 18 insertions(+), 18 deletions(-)
+
+--- a/net/mac80211/cfg.c
++++ b/net/mac80211/cfg.c
+@@ -2608,6 +2608,24 @@ static int ieee80211_start_roc_work(stru
+ INIT_DELAYED_WORK(&roc->work, ieee80211_sw_roc_work);
+ INIT_LIST_HEAD(&roc->dependents);
+
++ /*
++ * cookie is either the roc cookie (for normal roc)
++ * or the SKB (for mgmt TX)
++ */
++ if (!txskb) {
++ /* local->mtx protects this */
++ local->roc_cookie_counter++;
++ roc->cookie = local->roc_cookie_counter;
++ /* wow, you wrapped 64 bits ... more likely a bug */
++ if (WARN_ON(roc->cookie == 0)) {
++ roc->cookie = 1;
++ local->roc_cookie_counter++;
++ }
++ *cookie = roc->cookie;
++ } else {
++ *cookie = (unsigned long)txskb;
++ }
++
+ /* if there's one pending or we're scanning, queue this one */
+ if (!list_empty(&local->roc_list) ||
+ local->scanning || local->radar_detect_enabled)
+@@ -2742,24 +2760,6 @@ static int ieee80211_start_roc_work(stru
+ if (!queued)
+ list_add_tail(&roc->list, &local->roc_list);
+
+- /*
+- * cookie is either the roc cookie (for normal roc)
+- * or the SKB (for mgmt TX)
+- */
+- if (!txskb) {
+- /* local->mtx protects this */
+- local->roc_cookie_counter++;
+- roc->cookie = local->roc_cookie_counter;
+- /* wow, you wrapped 64 bits ... more likely a bug */
+- if (WARN_ON(roc->cookie == 0)) {
+- roc->cookie = 1;
+- local->roc_cookie_counter++;
+- }
+- *cookie = roc->cookie;
+- } else {
+- *cookie = (unsigned long)txskb;
+- }
+-
+ return 0;
+ }
+
--- /dev/null
+From 0297ea17bf7879fb5846fafd1be4c0471e72848d Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Mon, 27 Jan 2014 11:07:42 +0200
+Subject: mac80211: release the channel in error path in start_ap
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+commit 0297ea17bf7879fb5846fafd1be4c0471e72848d upstream.
+
+When the driver cannot start the AP or when the assignement
+of the beacon goes wrong, we need to unassign the vif.
+
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/cfg.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/mac80211/cfg.c
++++ b/net/mac80211/cfg.c
+@@ -995,8 +995,10 @@ static int ieee80211_start_ap(struct wip
+ IEEE80211_P2P_OPPPS_ENABLE_BIT;
+
+ err = ieee80211_assign_beacon(sdata, ¶ms->beacon);
+- if (err < 0)
++ if (err < 0) {
++ ieee80211_vif_release_channel(sdata);
+ return err;
++ }
+ changed |= err;
+
+ err = drv_start_ap(sdata->local, sdata);
+@@ -1005,6 +1007,7 @@ static int ieee80211_start_ap(struct wip
+ if (old)
+ kfree_rcu(old, rcu_head);
+ RCU_INIT_POINTER(sdata->u.ap.beacon, NULL);
++ ieee80211_vif_release_channel(sdata);
+ return err;
+ }
+
cifs-fix-smb2-mounts-so-they-don-t-try-to-set-or-get-xattrs-via-cifs.patch
add-protocol-specific-operation-for-cifs-xattrs.patch
retrieving-cifs-acls-when-mounted-with-smb2-fails-dropping-session.patch
+mac80211-move-roc-cookie-assignment-earlier.patch
+mac80211-release-the-channel-in-error-path-in-start_ap.patch
+mac80211-fix-ibss-disconnect.patch
+mac80211-fix-fragmentation-code-particularly-for-encryption.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
