3.10.9-100.fc18.gnu

10 files changed, 241 insertions, 277 deletions

diff --git a/freed-ora/current/f18/3.10.-6-7-crashes-on-network-activity.patch b/freed-ora/current/f18/3.10.-6-7-crashes-on-network-activity.patch
new file mode 100644
index 000000000..2e6b0d2ec
--- /dev/null
+++ b/freed-ora/current/f18/3.10.-6-7-crashes-on-network-activity.patch
@@ -0,0 +1,140 @@
+From 6aeddf9d409f3d9938b05b545d65810739237b2e Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@openwrt.org>
+Date: Tue, 20 Aug 2013 06:56:08 +0200
+Subject: [PATCH] 3.10.{6,7} crashes on network activity
+
+On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
+> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
+>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
+>> <gregkh@linuxfoundation.org> wrote:
+>> > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
+>> >> Hi guys,
+>> >>
+>> >> Starting with 3.10.6 (and still present in .7) I get an oops on
+>> >> connecting to the network.
+>> >>
+>> >> The attached picture shows the oops. In case it does not reach the ML,
+>> >> the top of the call trace reads:
+>> >>
+>> >> brcms_c_compute_rtscts_dur
+>> >> brcms_c_ampdu_finalize
+>> >> ampdu_finalize
+>> >> dma_txfast
+>> >> brcms_c_txfifo
+>> >> brcms_c_sendpkt_mac80211
+>> >> brcms_ops_tx
+>> >> __ieee80211_tx
+>> >>
+>> >> I bisected the problem and the first bad commit is
+>> >>
+>> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
+>> >> Author: Felix Fietkau <nbd@openwrt.org>
+>> >> Date:   Fri Jun 28 21:04:35 2013 +0200
+>> >>
+>> >>     mac80211/minstrel_ht: fix cck rate sampling
+>> >>
+>> >>     commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
+>> >>
+>> >> Reverting it on top of .7 fixes the problem.
+>> >>
+>> >> I had the same (I suppose) problem on mainline some time ago, but I
+>> >> have not bisected it, verified that the problem still occurs there, or
+>> >> checked if reverting the upstream patch fixes it. I'd be happy to do
+>> >> that if it would help though.
+>> >>
+>> >> Let me know if you need any more information.
+>> >
+>> > Do you have this same problem with 3.11-rc6 as well?
+>>
+>> Yes, I just confirmed. I also confirmed that reverting the mainline
+>> commit on top of -rc6 fixes the problem.
+>
+> Great, thanks.
+>
+> Felix and Johannes, any chance we can get this reverted in Linus tree
+> soon, and push that revert back to the 3.10 stable tree as well?
+I'd like to avoid a revert, since that will simply replace one set of
+issues with another. Let's limit the use of the feature that brcmsmac
+can't handle to drivers that are known to work with it. Tom, Please
+test this patch to see if it fixes your issue.
+
+- Felix
+---
+ drivers/net/wireless/ath/ath9k/init.c    | 3 ++-
+ drivers/net/wireless/ath/carl9170/main.c | 3 ++-
+ drivers/net/wireless/rt2x00/rt2800lib.c  | 3 ++-
+ include/net/mac80211.h                   | 1 +
+ net/mac80211/rc80211_minstrel_ht.c       | 3 +++
+ 5 files changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
+index 2ba4945..bd126c2 100644
+--- a/drivers/net/wireless/ath/ath9k/init.c
++++ b/drivers/net/wireless/ath/ath9k/init.c
+@@ -767,7 +767,8 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
+ 		IEEE80211_HW_PS_NULLFUNC_STACK |
+ 		IEEE80211_HW_SPECTRUM_MGMT |
+ 		IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+-		IEEE80211_HW_SUPPORTS_RC_TABLE;
++		IEEE80211_HW_SUPPORTS_RC_TABLE |
++		IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
+ 
+ 	if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
+ 		 hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
+index e9010a4..0686375 100644
+--- a/drivers/net/wireless/ath/carl9170/main.c
++++ b/drivers/net/wireless/ath/carl9170/main.c
+@@ -1857,7 +1857,8 @@ void *carl9170_alloc(size_t priv_size)
+ 		     IEEE80211_HW_SUPPORTS_PS |
+ 		     IEEE80211_HW_PS_NULLFUNC_STACK |
+ 		     IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
+-		     IEEE80211_HW_SIGNAL_DBM;
++		     IEEE80211_HW_SIGNAL_DBM |
++		     IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
+ 
+ 	if (!modparam_noht) {
+ 		/*
+diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
+index 705aa33..7e66a90 100644
+--- a/drivers/net/wireless/rt2x00/rt2800lib.c
++++ b/drivers/net/wireless/rt2x00/rt2800lib.c
+@@ -5912,7 +5912,8 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
+ 	    IEEE80211_HW_SUPPORTS_PS |
+ 	    IEEE80211_HW_PS_NULLFUNC_STACK |
+ 	    IEEE80211_HW_AMPDU_AGGREGATION |
+-	    IEEE80211_HW_REPORTS_TX_ACK_STATUS;
++	    IEEE80211_HW_REPORTS_TX_ACK_STATUS |
++	    IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
+ 
+ 	/*
+ 	 * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
+diff --git a/include/net/mac80211.h b/include/net/mac80211.h
+index 885898a..4e50d36 100644
+--- a/include/net/mac80211.h
++++ b/include/net/mac80211.h
+@@ -1484,6 +1484,7 @@ enum ieee80211_hw_flags {
+ 	IEEE80211_HW_SUPPORTS_RC_TABLE			= 1<<24,
+ 	IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF		= 1<<25,
+ 	IEEE80211_HW_TIMING_BEACON_ONLY			= 1<<26,
++	IEEE80211_HW_SUPPORTS_HT_CCK_RATES		= 1<<27,
+ };
+ 
+ /**
+diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
+index f5aed96..f3bbea1 100644
+--- a/net/mac80211/rc80211_minstrel_ht.c
++++ b/net/mac80211/rc80211_minstrel_ht.c
+@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_priv *mp, struct minstrel_ht_sta *mi,
+ 	if (sband->band != IEEE80211_BAND_2GHZ)
+ 		return;
+ 
++	if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
++		return;
++
+ 	mi->cck_supported = 0;
+ 	mi->cck_supported_short = 0;
+ 	for (i = 0; i < 4; i++) {
+-- 
+1.8.3.1
+
diff --git a/freed-ora/current/f18/ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch b/freed-ora/current/f18/ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch
new file mode 100644
index 000000000..0c4fc2484
--- /dev/null
+++ b/freed-ora/current/f18/ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch
@@ -0,0 +1,63 @@
+From 2712c283acc085b5438fa1b22053423a0158468d Mon Sep 17 00:00:00 2001
+From: Hannes Frederic Sowa <hannes@stressinduktion.org>
+Date: Fri, 16 Aug 2013 11:02:27 +0000
+Subject: [PATCH] ipv6: remove max_addresses check from ipv6_create_tempaddr
+
+Because of the max_addresses check attackers were able to disable privacy
+extensions on an interface by creating enough autoconfigured addresses:
+
+<http://seclists.org/oss-sec/2012/q4/292>
+
+But the check is not actually needed: max_addresses protects the
+kernel to install too many ipv6 addresses on an interface and guards
+addrconf_prefix_rcv to install further addresses as soon as this limit
+is reached. We only generate temporary addresses in direct response of
+a new address showing up. As soon as we filled up the maximum number of
+addresses of an interface, we stop installing more addresses and thus
+also stop generating more temp addresses.
+
+Even if the attacker tries to generate a lot of temporary addresses
+by announcing a prefix and removing it again (lifetime == 0) we won't
+install more temp addresses, because the temporary addresses do count
+to the maximum number of addresses, thus we would stop installing new
+autoconfigured addresses when the limit is reached.
+
+This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
+possible).
+
+Thanks to Ding Tianhong to bring this topic up again.
+
+Cc: Ding Tianhong <dingtianhong@huawei.com>
+Cc: George Kargiotakis <kargig@void.gr>
+Cc: P J P <ppandit@redhat.com>
+Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
+Acked-by: Ding Tianhong <dingtianhong@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+---
+ net/ipv6/addrconf.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
+index fb8c94c..21b7a87 100644
+--- a/net/ipv6/addrconf.c
++++ b/net/ipv6/addrconf.c
+@@ -1124,12 +1124,10 @@ retry:
+ 	if (ifp->flags & IFA_F_OPTIMISTIC)
+ 		addr_flags |= IFA_F_OPTIMISTIC;
+ 
+-	ift = !max_addresses ||
+-	      ipv6_count_addresses(idev) < max_addresses ?
+-		ipv6_add_addr(idev, &addr, tmp_plen,
++	ift = ipv6_add_addr(idev, &addr, tmp_plen,
+ 			      ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
+-			      addr_flags) : NULL;
+-	if (IS_ERR_OR_NULL(ift)) {
++			      addr_flags);
++	if (IS_ERR(ift)) {
+ 		in6_ifa_put(ifp);
+ 		in6_dev_put(idev);
+ 		pr_info("%s: retry temporary address regeneration\n", __func__);
+-- 
+1.8.3.1
+
diff --git a/freed-ora/current/f18/iwl4965-reset-firmware-after-rfkill-off.patch b/freed-ora/current/f18/iwl4965-reset-firmware-after-rfkill-off.patch
deleted file mode 100644
index 08b360d10..000000000
--- a/freed-ora/current/f18/iwl4965-reset-firmware-after-rfkill-off.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-Using rfkill switch can make firmware unstable, what cause various
-Microcode errors and kernel warnings. Reseting firmware just after
-rfkill off (radio on) helped with that.
-
-Resolve:
-https://bugzilla.redhat.com/show_bug.cgi?id=977053
-
-Reported-and-tested-by: Justin Pearce <whitefox@guardianfox.net>
-Cc: stable@vger.kernel.org
-Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
----
- drivers/net/wireless/iwlegacy/4965-mac.c | 10 +++++-----
- drivers/net/wireless/iwlegacy/common.c   |  1 +
- 2 files changed, 6 insertions(+), 5 deletions(-)
-
-diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
-index f0b7794..f2ed62e 100644
---- a/drivers/net/wireless/iwlegacy/4965-mac.c
-+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
-@@ -4460,12 +4460,12 @@ il4965_irq_tasklet(struct il_priv *il)
- 		 * is killed. Hence update the killswitch state here. The
- 		 * rfkill handler will care about restarting if needed.
- 		 */
--		if (!test_bit(S_ALIVE, &il->status)) {
--			if (hw_rf_kill)
--				set_bit(S_RFKILL, &il->status);
--			else
--				clear_bit(S_RFKILL, &il->status);
-+		if (hw_rf_kill) {
-+			set_bit(S_RFKILL, &il->status);
-+		} else {
-+			clear_bit(S_RFKILL, &il->status);
- 			wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
-+			il_force_reset(il, true);
- 		}
- 
- 		handled |= CSR_INT_BIT_RF_KILL;
-diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
-index 3195aad..b03e22e 100644
---- a/drivers/net/wireless/iwlegacy/common.c
-+++ b/drivers/net/wireless/iwlegacy/common.c
-@@ -4660,6 +4660,7 @@ il_force_reset(struct il_priv *il, bool external)
- 
- 	return 0;
- }
-+EXPORT_SYMBOL(il_force_reset);
- 
- int
- il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
--- 
-1.7.11.7
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
\ No newline at end of file
diff --git a/freed-ora/current/f18/kernel.spec b/freed-ora/current/f18/kernel.spec
index d419f866b..9d296897e 100644
--- a/freed-ora/current/f18/kernel.spec
+++ b/freed-ora/current/f18/kernel.spec
@@ -112,7 +112,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 7
+%define stable_update 9
 # Is it a -stable RC?
 %define stable_rc 0
 # Set rpm version accordingly
@@ -830,17 +830,15 @@ Patch25069: iwlwifi-dvm-fix-calling-ieee80211_chswitch_done-with-NULL.patch
 #rhbz 969473
 Patch25070: Input-elantech-fix-for-newer-hardware-versions-v7.patch
 
-#rhbz 977053
-Patch25073: iwl4965-reset-firmware-after-rfkill-off.patch
-
-#rhbz 981445
-Patch25074: mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch
-Patch25075: mac80211-ignore-HT-primary-channel-while-connected.patch
-Patch25076: mac80211-continue-using-disabled-channels-while-connected.patch
-
 #rhbz 963715
 Patch25077: media-cx23885-Fix-TeVii-S471-regression-since-introduction-of-ts2020.patch
 
+#CVE-2013-0343 rhbz 914664 999380
+Patch25078: ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch
+
+#rhbz 989269
+Patch25079: 3.10.-6-7-crashes-on-network-activity.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -1606,17 +1604,15 @@ ApplyPatch iwlwifi-dvm-fix-calling-ieee80211_chswitch_done-with-NULL.patch
 #rhbz 969473
 ApplyPatch Input-elantech-fix-for-newer-hardware-versions-v7.patch
 
-#rhbz 977053
-ApplyPatch iwl4965-reset-firmware-after-rfkill-off.patch
-
-#rhbz 981445
-ApplyPatch mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch
-ApplyPatch mac80211-ignore-HT-primary-channel-while-connected.patch
-ApplyPatch mac80211-continue-using-disabled-channels-while-connected.patch
-
 #rhbz 963715
 ApplyPatch media-cx23885-Fix-TeVii-S471-regression-since-introduction-of-ts2020.patch
 
+#CVE-2013-0343 rhbz 914664 999380
+ApplyPatch ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch
+
+#rhbz 989269
+ApplyPatch 3.10.-6-7-crashes-on-network-activity.patch
+
 # END OF PATCH APPLICATIONS
 
 %endif
@@ -2469,6 +2465,23 @@ fi
 #                 ||----w |
 #                 ||     ||
 %changelog
+* Wed Aug 21 2013 Alexandre Oliva <lxoliva@fsfla.org> -libre
+- GNU Linux-libre 3.10.9-gnu.
+
+* Wed Aug 21 2013 Josh Boyer <jwboyer@fedoraproject.org>
+- Add patch to fix brcmsmac oops (rhbz 989269)
+- CVE-2013-0343 handling of IPv6 temporary addresses (rhbz 914664 999380)
+
+* Tue Aug 20 2013 Josh Boyer <jwboyer@fedoraproject.org>
+- Linux v3.10.9
+
+* Tue Aug 20 2013 Josh Boyer <jwboyer@fedoraproject.org> - 3.10.8-100
+- Linux v3.10.8
+- CVE-2013-4254 ARM: perf: NULL pointer dereference in validate_event (rhbz 998878 998881)
+
+* Fri Aug 16 2013 Josh Boyer <jwboyer@fedoraproject.org>
+- Add patch from Nathanael Noblet to fix mic on Gateway LT27 (rhbz 845699)
+
 * Thu Aug 15 2013 Alexandre Oliva <lxoliva@fsfla.org> -libre
 - GNU Linux-libre 3.10.7-gnu.
 
diff --git a/freed-ora/current/f18/mac80211-continue-using-disabled-channels-while-connected.patch b/freed-ora/current/f18/mac80211-continue-using-disabled-channels-while-connected.patch
deleted file mode 100644
index 91dd1d7db..000000000
--- a/freed-ora/current/f18/mac80211-continue-using-disabled-channels-while-connected.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From ddfe49b42d8ad4bfdf92d63d4a74f162660d878d Mon Sep 17 00:00:00 2001
-From: Johannes Berg <johannes.berg@intel.com>
-Date: Wed, 31 Jul 2013 18:52:03 +0000
-Subject: mac80211: continue using disabled channels while connected
-
-In case the AP has different regulatory information than we do,
-it can happen that we connect to an AP based on e.g. the world
-roaming regulatory data, and then update our database with the
-AP's country information disables the channel the AP is using.
-If this happens on an HT AP, the bandwidth tracking code will
-hit the WARN_ON() and disconnect. Since that's not very useful,
-ignore the channel-disable flag in bandwidth tracking.
-
-Cc: stable@vger.kernel.org
-Reported-by: Chris Wright <chrisw@sous-sol.org>
-Tested-by: Chris Wright <chrisw@sous-sol.org>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
-index 077a953..cc9e02d 100644
---- a/net/mac80211/mlme.c
-+++ b/net/mac80211/mlme.c
-@@ -335,8 +335,17 @@ out:
- 	if (ret & IEEE80211_STA_DISABLE_VHT)
- 		vht_chandef = *chandef;
- 
-+	/*
-+	 * Ignore the DISABLED flag when we're already connected and only
-+	 * tracking the APs beacon for bandwidth changes - otherwise we
-+	 * might get disconnected here if we connect to an AP, update our
-+	 * regulatory information based on the AP's country IE and the
-+	 * information we have is wrong/outdated and disables the channel
-+	 * that we're actually using for the connection to the AP.
-+	 */
- 	while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
--					IEEE80211_CHAN_DISABLED)) {
-+					tracking ? 0 :
-+						   IEEE80211_CHAN_DISABLED)) {
- 		if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
- 			ret = IEEE80211_STA_DISABLE_HT |
- 			      IEEE80211_STA_DISABLE_VHT;
---
-cgit v0.9.2
diff --git a/freed-ora/current/f18/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch b/freed-ora/current/f18/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch
deleted file mode 100644
index 49115f969..000000000
--- a/freed-ora/current/f18/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From b56e4b857c5210e848bfb80e074e5756a36cd523 Mon Sep 17 00:00:00 2001
-From: Chris Wright <chrisw@sous-sol.org>
-Date: Wed, 31 Jul 2013 19:12:24 +0000
-Subject: mac80211: fix infinite loop in ieee80211_determine_chantype
-
-Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
-infinite loop by moving the out target above the chandef_downgrade
-while loop.  When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
-back up to re-run the while loop...indefinitely.  Replace goto with
-break and carry on.  This may not be sufficient to connect to the AP,
-but will at least keep the cpu from livelocking.  Thanks to Derek Atkins
-as an extra pair of debugging eyes.
-
-Cc: stable@kernel.org
-Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
-index ae31968..e3e7d2b 100644
---- a/net/mac80211/mlme.c
-+++ b/net/mac80211/mlme.c
-@@ -338,7 +338,7 @@ out:
- 		if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
- 			ret = IEEE80211_STA_DISABLE_HT |
- 			      IEEE80211_STA_DISABLE_VHT;
--			goto out;
-+			break;
- 		}
- 
- 		ret |= chandef_downgrade(chandef);
---
-cgit v0.9.2
diff --git a/freed-ora/current/f18/mac80211-ignore-HT-primary-channel-while-connected.patch b/freed-ora/current/f18/mac80211-ignore-HT-primary-channel-while-connected.patch
deleted file mode 100644
index ba5d2a478..000000000
--- a/freed-ora/current/f18/mac80211-ignore-HT-primary-channel-while-connected.patch
+++ /dev/null
@@ -1,121 +0,0 @@
-From 5cdaed1e878d723d56d04ae0be1738124acf9f46 Mon Sep 17 00:00:00 2001
-From: Johannes Berg <johannes.berg@intel.com>
-Date: Wed, 31 Jul 2013 09:23:06 +0000
-Subject: mac80211: ignore HT primary channel while connected
-
-While we're connected, the AP shouldn't change the primary channel
-in the HT information. We checked this, and dropped the connection
-if it did change it.
-
-Unfortunately, this is causing problems on some APs, e.g. on the
-Netgear WRT610NL: the beacons seem to always contain a bad channel
-and if we made a connection using a probe response (correct data)
-we drop the connection immediately and can basically not connect
-properly at all.
-
-Work around this by ignoring the HT primary channel information in
-beacons if we're already connected.
-
-Also print out more verbose messages in the other situations to
-help diagnose similar bugs quicker in the future.
-
-Cc: stable@vger.kernel.org [3.10]
-Acked-by: Andy Isaacson <adi@hexapodia.org>
-Signed-off-by: Johannes Berg <johannes.berg@intel.com>
----
-diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
-index e5c3cf4..077a953 100644
---- a/net/mac80211/mlme.c
-+++ b/net/mac80211/mlme.c
-@@ -211,8 +211,9 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
- 			     struct ieee80211_channel *channel,
- 			     const struct ieee80211_ht_operation *ht_oper,
- 			     const struct ieee80211_vht_operation *vht_oper,
--			     struct cfg80211_chan_def *chandef, bool verbose)
-+			     struct cfg80211_chan_def *chandef, bool tracking)
- {
-+	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- 	struct cfg80211_chan_def vht_chandef;
- 	u32 ht_cfreq, ret;
- 
-@@ -231,7 +232,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
- 	ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan,
- 						  channel->band);
- 	/* check that channel matches the right operating channel */
--	if (channel->center_freq != ht_cfreq) {
-+	if (!tracking && channel->center_freq != ht_cfreq) {
- 		/*
- 		 * It's possible that some APs are confused here;
- 		 * Netgear WNDR3700 sometimes reports 4 higher than
-@@ -239,11 +240,10 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
- 		 * since we look at probe response/beacon data here
- 		 * it should be OK.
- 		 */
--		if (verbose)
--			sdata_info(sdata,
--				   "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
--				   channel->center_freq, ht_cfreq,
--				   ht_oper->primary_chan, channel->band);
-+		sdata_info(sdata,
-+			   "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
-+			   channel->center_freq, ht_cfreq,
-+			   ht_oper->primary_chan, channel->band);
- 		ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
- 		goto out;
- 	}
-@@ -297,7 +297,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
- 				channel->band);
- 		break;
- 	default:
--		if (verbose)
-+		if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
- 			sdata_info(sdata,
- 				   "AP VHT operation IE has invalid channel width (%d), disable VHT\n",
- 				   vht_oper->chan_width);
-@@ -306,7 +306,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
- 	}
- 
- 	if (!cfg80211_chandef_valid(&vht_chandef)) {
--		if (verbose)
-+		if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
- 			sdata_info(sdata,
- 				   "AP VHT information is invalid, disable VHT\n");
- 		ret = IEEE80211_STA_DISABLE_VHT;
-@@ -319,7 +319,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
- 	}
- 
- 	if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) {
--		if (verbose)
-+		if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
- 			sdata_info(sdata,
- 				   "AP VHT information doesn't match HT, disable VHT\n");
- 		ret = IEEE80211_STA_DISABLE_VHT;
-@@ -346,7 +346,7 @@ out:
- 		ret |= chandef_downgrade(chandef);
- 	}
- 
--	if (chandef->width != vht_chandef.width && verbose)
-+	if (chandef->width != vht_chandef.width && !tracking)
- 		sdata_info(sdata,
- 			   "capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n");
- 
-@@ -386,7 +386,7 @@ static int ieee80211_config_bw(struct ieee80211_sub_if_data *sdata,
- 
- 	/* calculate new channel (type) based on HT/VHT operation IEs */
- 	flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper,
--					     vht_oper, &chandef, false);
-+					     vht_oper, &chandef, true);
- 
- 	/*
- 	 * Downgrade the new channel if we associated with restricted
-@@ -3838,7 +3838,7 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
- 	ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
- 						     cbss->channel,
- 						     ht_oper, vht_oper,
--						     &chandef, true);
-+						     &chandef, false);
- 
- 	sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss),
- 				      local->rx_chains);
---
-cgit v0.9.2
diff --git a/freed-ora/current/f18/patch-3.10-gnu-3.10.7-gnu.xz.sign b/freed-ora/current/f18/patch-3.10-gnu-3.10.7-gnu.xz.sign
deleted file mode 100644
index 7ec555505..000000000
--- a/freed-ora/current/f18/patch-3.10-gnu-3.10.7-gnu.xz.sign
+++ /dev/null
@@ -1,7 +0,0 @@
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v2.0.19 (GNU/Linux)
-
-iEYEABECAAYFAlINNCkACgkQvLfPh359R6d+VgCfZ5IDuYgwvFxl3DmCGGAAZ2GN
-rgcAn19RHhD8yY5I1PsmE0bjt+CGC14Y
-=bYR9
------END PGP SIGNATURE-----
diff --git a/freed-ora/current/f18/patch-3.10-gnu-3.10.9-gnu.xz.sign b/freed-ora/current/f18/patch-3.10-gnu-3.10.9-gnu.xz.sign
new file mode 100644
index 000000000..681efc247
--- /dev/null
+++ b/freed-ora/current/f18/patch-3.10-gnu-3.10.9-gnu.xz.sign
@@ -0,0 +1,7 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2.0.19 (GNU/Linux)
+
+iEYEABECAAYFAlIUL0sACgkQvLfPh359R6dkwACggEmHHThn2ZIsrWunYCkWic4R
+JOIAnj2JDOiLHFayW4/3CQZvZyrQhsu8
+=YFWR
+-----END PGP SIGNATURE-----
diff --git a/freed-ora/current/f18/sources b/freed-ora/current/f18/sources
index 3232d9c50..02b7f4a1c 100644
--- a/freed-ora/current/f18/sources
+++ b/freed-ora/current/f18/sources
@@ -1,2 +1,2 @@
 d562fd52580a3b6b18b6eeb5921d1d5c  linux-libre-3.10-gnu.tar.xz
-8d05dec5772b17c4c21c00b93da42bd8  patch-3.10-gnu-3.10.7-gnu.xz
+312e4b4203d2e74201a14f1a9633482d  patch-3.10-gnu-3.10.9-gnu.xz