From 7e6225a1604d0c6aa4140289bf5761868ffc9c83 Mon Sep 17 00:00:00 2001 From: Jes Sorensen Date: Wed, 10 Dec 2014 14:14:07 -0500 Subject: mac80211: avoid using uninitialized stack data Avoid a case where we would access uninitialized stack data if the AP advertises HT support without 40MHz channel support. Cc: stable@vger.kernel.org Fixes: f3000e1b43f1 ("mac80211: fix broken use of VHT/20Mhz with some APs") Signed-off-by: Jes Sorensen Signed-off-by: Johannes Berg --- net/mac80211/mlme.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 75a9bf50207e..2c36c4765f47 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -174,6 +174,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, if (!(ht_cap->cap_info & cpu_to_le16(IEEE80211_HT_CAP_SUP_WIDTH_20_40))) { ret = IEEE80211_STA_DISABLE_40MHZ; + vht_chandef = *chandef; goto out; } -- cgit v1.2.3-59-g8ed1b From d025933e29872cb1fe19fc54d80e4dfa4ee5779c Mon Sep 17 00:00:00 2001 From: Andreas Müller Date: Fri, 12 Dec 2014 12:11:11 +0100 Subject: mac80211: fix multicast LED blinking and counter MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount" stopped being incremented after the use-after-free fix. Furthermore, the RX-LED will be triggered by every multicast frame (which wouldn't happen before) which wouldn't allow the LED to rest at all. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the patch. Cc: stable@vger.kernel.org Fixes: b8fff407a180 ("mac80211: fix use-after-free in defragmentation") Signed-off-by: Andreas Müller [rewrite commit message] Signed-off-by: Johannes Berg --- net/mac80211/rx.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 49c23bdf08bb..683b10f46505 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -1761,14 +1761,14 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx) sc = le16_to_cpu(hdr->seq_ctrl); frag = sc & IEEE80211_SCTL_FRAG; - if (likely(!ieee80211_has_morefrags(fc) && frag == 0)) - goto out; - if (is_multicast_ether_addr(hdr->addr1)) { rx->local->dot11MulticastReceivedFrameCount++; - goto out; + goto out_no_led; } + if (likely(!ieee80211_has_morefrags(fc) && frag == 0)) + goto out; + I802_DEBUG_INC(rx->local->rx_handlers_fragments); if (skb_linearize(rx->skb)) @@ -1859,9 +1859,10 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx) status->rx_flags |= IEEE80211_RX_FRAGMENTED; out: + ieee80211_led_rx(rx->local); + out_no_led: if (rx->sta) rx->sta->rx_packets++; - ieee80211_led_rx(rx->local); return RX_CONTINUE; } -- cgit v1.2.3-59-g8ed1b From 08f6f147773b23b765b94633a8eaa82e7defcf4c Mon Sep 17 00:00:00 2001 From: Jouni Malinen Date: Thu, 11 Dec 2014 23:48:55 +0200 Subject: cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers The VHT supported channel width field is a two bit integer, not a bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and ended up rejecting 160 MHz channel width if the driver indicated support for both 160 and 80+80 MHz channels. Cc: stable@vger.kernel.org (3.16+) Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration") (however, no real drivers had 160 MHz support it until 3.16) Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg --- net/wireless/chan.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/net/wireless/chan.c b/net/wireless/chan.c index 85506f1d0789..7aaf7415dc4c 100644 --- a/net/wireless/chan.c +++ b/net/wireless/chan.c @@ -603,7 +603,7 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy, { struct ieee80211_sta_ht_cap *ht_cap; struct ieee80211_sta_vht_cap *vht_cap; - u32 width, control_freq; + u32 width, control_freq, cap; if (WARN_ON(!cfg80211_chandef_valid(chandef))) return false; @@ -643,7 +643,8 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy, return false; break; case NL80211_CHAN_WIDTH_80P80: - if (!(vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)) + cap = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK; + if (cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ) return false; case NL80211_CHAN_WIDTH_80: if (!vht_cap->vht_supported) @@ -654,7 +655,9 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy, case NL80211_CHAN_WIDTH_160: if (!vht_cap->vht_supported) return false; - if (!(vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ)) + cap = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK; + if (cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ && + cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ) return false; prohibited_flags |= IEEE80211_CHAN_NO_160MHZ; width = 160; -- cgit v1.2.3-59-g8ed1b From 34f05f543f02350e920bddb7660ffdd4697aaf60 Mon Sep 17 00:00:00 2001 From: Arik Nemtsov Date: Thu, 4 Dec 2014 12:22:16 +0200 Subject: cfg80211: avoid mem leak on driver hint set In the already-set and intersect case of a driver-hint, the previous wiphy regdomain was not freed before being reset with a copy of the cfg80211 regdomain. Cc: stable@vger.kernel.org Signed-off-by: Arik Nemtsov Acked-by: Luis R. Rodriguez Signed-off-by: Johannes Berg --- net/wireless/reg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 47be6163381c..7ddd16a51adf 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1907,7 +1907,7 @@ static enum reg_request_treatment reg_process_hint_driver(struct wiphy *wiphy, struct regulatory_request *driver_request) { - const struct ieee80211_regdomain *regd; + const struct ieee80211_regdomain *regd, *tmp; enum reg_request_treatment treatment; treatment = __reg_process_hint_driver(driver_request); @@ -1927,7 +1927,10 @@ reg_process_hint_driver(struct wiphy *wiphy, reg_free_request(driver_request); return REG_REQ_IGNORE; } + + tmp = get_wiphy_regdom(wiphy); rcu_assign_pointer(wiphy->regd, regd); + rcu_free_regdom(tmp); } -- cgit v1.2.3-59-g8ed1b From f89f46cf3a23d8d7c98f924a461fd931e1331746 Mon Sep 17 00:00:00 2001 From: Luciano Coelho Date: Mon, 1 Dec 2014 11:32:09 +0200 Subject: nl80211: check matches array length before acessing it If the userspace passes a malformed sched scan request (or a net detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH attribute without any nested matchsets, a NULL pointer dereference will occur. Fix this by checking that we do have matchsets in our array before trying to access it. BUG: unable to handle kernel NULL pointer dereference at 0000000000000024 IP: [] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] PGD 865c067 PUD 865b067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat] CPU: 2 PID: 2442 Comm: iw Tainted: G O 3.17.2 #31 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000 RIP: 0010:[] [] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] RSP: 0018:ffff880008d838d0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0 RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019 R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00 R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388 FS: 00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0 Stack: ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0 0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948 ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000 Call Trace: [] ? nla_parse+0xb9/0x120 [] nl80211_set_wowlan+0x75e/0x960 [cfg80211] [] ? mark_held_locks+0x75/0xa0 [] genl_family_rcv_msg+0x18b/0x360 [] ? trace_hardirqs_on+0xd/0x10 [] genl_rcv_msg+0x84/0xc0 [] ? genl_family_rcv_msg+0x360/0x360 [] netlink_rcv_skb+0xa9/0xd0 [] genl_rcv+0x28/0x40 [] netlink_unicast+0x105/0x180 [] netlink_sendmsg+0x34f/0x7a0 [] ? kvm_clock_read+0x27/0x40 [] sock_sendmsg+0x8d/0xc0 [] ? might_fault+0xb9/0xc0 [] ? might_fault+0x5e/0xc0 [] ? verify_iovec+0x56/0xe0 [] ___sys_sendmsg+0x3d0/0x3e0 [] ? sched_clock_cpu+0x98/0xd0 [] ? __do_page_fault+0x254/0x580 [] ? up_read+0x1f/0x40 [] ? __do_page_fault+0x254/0x580 [] ? __fget_light+0x13d/0x160 [] __sys_sendmsg+0x42/0x80 [] SyS_sendmsg+0x12/0x20 [] system_call_fastpath+0x16/0x1b Fixes: ea73cbce4e1f ("nl80211: fix scheduled scan RSSI matchset attribute confusion") Cc: stable@vger.kernel.org [3.15+] Signed-off-by: Luciano Coelho Signed-off-by: Johannes Berg --- net/wireless/nl80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index a17d6bc6b22c..7ca4b5133123 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -6002,7 +6002,7 @@ nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev, } /* there was no other matchset, so the RSSI one is alone */ - if (i == 0) + if (i == 0 && n_match_sets) request->match_sets[0].rssi_thold = default_match_rssi; request->min_rssi_thold = INT_MAX; -- cgit v1.2.3-59-g8ed1b From 722ddb0dab29b666881d74067c2b92d42074351f Mon Sep 17 00:00:00 2001 From: Emmanuel Grumbach Date: Sun, 30 Nov 2014 17:17:26 +0200 Subject: mac80211: update the channel context after channel switch When the channel switch has been made, a vif is now using the channel context which was reserved. When that happens, we need to update the channel context since its parameters may change. I hit a case in which I switched to a 40Mhz channel but the reserved channel context was still on 20Mhz. The rate control would try to send 40Mhz packets on a 20Mhz channel context and that made iwlwifi's firmware unhappy. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg --- net/mac80211/chan.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c index 5d6dae9e4aac..da1c12c34487 100644 --- a/net/mac80211/chan.c +++ b/net/mac80211/chan.c @@ -1011,6 +1011,10 @@ ieee80211_vif_use_reserved_reassign(struct ieee80211_sub_if_data *sdata) ieee80211_vif_update_chandef(sdata, &sdata->reserved_chandef); + ieee80211_recalc_smps_chanctx(local, new_ctx); + ieee80211_recalc_radar_chanctx(local, new_ctx); + ieee80211_recalc_chanctx_min_def(local, new_ctx); + if (changed) ieee80211_bss_info_change_notify(sdata, changed); -- cgit v1.2.3-59-g8ed1b From 70dcec5a488a7b81779190ac8089475fe4b8b962 Mon Sep 17 00:00:00 2001 From: Emmanuel Grumbach Date: Tue, 2 Dec 2014 09:53:25 +0200 Subject: cfg80211: don't WARN about two consecutive Country IE hint This can happen and there is no point in added more detection code lower in the stack. Catching these in one single point (cfg80211) is enough. Stop WARNING about this case. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=89001 Cc: stable@vger.kernel.org Fixes: 2f1c6c572d7b ("cfg80211: process non country IE conflicting first") Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg --- net/wireless/reg.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 7ddd16a51adf..c9f5ad5d5d94 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1989,11 +1989,8 @@ __reg_process_hint_country_ie(struct wiphy *wiphy, return REG_REQ_IGNORE; return REG_REQ_ALREADY_SET; } - /* - * Two consecutive Country IE hints on the same wiphy. - * This should be picked up early by the driver/stack - */ - if (WARN_ON(regdom_changes(country_ie_request->alpha2))) + + if (regdom_changes(country_ie_request->alpha2)) return REG_REQ_OK; return REG_REQ_ALREADY_SET; } -- cgit v1.2.3-59-g8ed1b From 185076d6db7b0320fd7669732923179f9a4d068b Mon Sep 17 00:00:00 2001 From: Arik Nemtsov Date: Wed, 3 Dec 2014 18:08:17 +0200 Subject: cfg80211: correctly check ad-hoc channels Ad-hoc requires beaconing for regulatory purposes. Validate that the channel is valid for beaconing, and not only enabled. Signed-off-by: Arik Nemtsov Reviewed-by: Luis R. Rodriguez Signed-off-by: Johannes Berg --- net/wireless/reg.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index c9f5ad5d5d94..7b8309840d4e 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1546,12 +1546,18 @@ static bool reg_wdev_chan_valid(struct wiphy *wiphy, struct wireless_dev *wdev) if (!wdev->beacon_interval) goto out; + ret = cfg80211_reg_can_beacon(wiphy, + &wdev->chandef, wdev->iftype); + break; + case NL80211_IFTYPE_ADHOC: + if (!wdev->ssid_len) + goto out; + ret = cfg80211_reg_can_beacon(wiphy, &wdev->chandef, wdev->iftype); break; case NL80211_IFTYPE_STATION: case NL80211_IFTYPE_P2P_CLIENT: - case NL80211_IFTYPE_ADHOC: if (!wdev->current_bss || !wdev->current_bss->pub.channel) goto out; -- cgit v1.2.3-59-g8ed1b From 28a9bc68124c319b2b3dc861e80828a8865fd1ba Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Wed, 17 Dec 2014 13:55:49 +0100 Subject: mac80211: free management frame keys when removing station When writing the code to allow per-station GTKs, I neglected to take into account the management frame keys (index 4 and 5) when freeing the station and only added code to free the first four data frame keys. Fix this by iterating the array of keys over the right length. Cc: stable@vger.kernel.org Fixes: e31b82136d1a ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by: Johannes Berg --- net/mac80211/key.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/key.c b/net/mac80211/key.c index 434a91ad12c8..0bb7038121ac 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -656,7 +656,7 @@ void ieee80211_free_sta_keys(struct ieee80211_local *local, int i; mutex_lock(&local->key_mtx); - for (i = 0; i < NUM_DEFAULT_KEYS; i++) { + for (i = 0; i < ARRAY_SIZE(sta->gtk); i++) { key = key_mtx_dereference(local, sta->gtk[i]); if (!key) continue; -- cgit v1.2.3-59-g8ed1b