From 8ccd8f21122dcc30a665516d43aa8b4aa8ae51f6 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Wed, 29 Apr 2009 23:35:56 +0200 Subject: mac80211: correct fragmentation threshold check The fragmentation threshold is defined to be including the FCS, and the code that sets the TX_FRAGMENTED flag correctly accounts for those four bytes. The code that verifies this doesn't though, which could lead to spurious warnings and frames being dropped although everything is ok. Correct the code by accounting for the FCS. (JWL -- The problem is described here: http://article.gmane.org/gmane.linux.kernel.wireless.general/32205 ) Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- net/mac80211/tx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'net') diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 3fb04a8..6365626 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -772,7 +772,7 @@ ieee80211_tx_h_fragment(struct ieee80211_tx_data *tx) hdrlen = ieee80211_hdrlen(hdr->frame_control); /* internal error, why is TX_FRAGMENTED set? */ - if (WARN_ON(skb->len <= frag_threshold)) + if (WARN_ON(skb->len + FCS_LEN <= frag_threshold)) return TX_DROP; /* -- cgit v1.1 From c0f0aac05fa84b37ed46db8cf6c8bee9a67bbcca Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Thu, 30 Apr 2009 20:09:56 +0200 Subject: cfg80211: fix truncated IEs Another bug in the "cfg80211: do not replace BSS structs" patch, a forgotten length update leads to bogus data being stored and passed to userspace, often truncated. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- net/wireless/scan.c | 1 + 1 file changed, 1 insertion(+) (limited to 'net') diff --git a/net/wireless/scan.c b/net/wireless/scan.c index 2ae65b3..1f260c4 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -395,6 +395,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev, memcpy(ies, res->pub.information_elements, ielen); found->ies_allocated = true; found->pub.information_elements = ies; + found->pub.len_information_elements = ielen; } } } -- cgit v1.1 From ac46d48e00349c63650b3cc6f9460fcc183da6a6 Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" Date: Fri, 1 May 2009 18:44:50 -0400 Subject: cfg80211: fix race condition with wiphy_apply_custom_regulatory() We forgot to lock using the cfg80211_mutex in wiphy_apply_custom_regulatory(). Without the lock there is possible race between processing a reply from CRDA and a driver calling wiphy_apply_custom_regulatory(). During the processing of the reply from CRDA we free last_request and wiphy_apply_custom_regulatory() eventually accesses an element from last_request in the through freq_reg_info_regd(). This is very difficult to reproduce (I haven't), it takes us 3 hours and you need to be banging hard, but the race is obvious by looking at the code. This should only affect those who use this caller, which currently is ath5k, ath9k, and ar9170. EIP: 0060:[] EFLAGS: 00210282 CPU: 1 EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211] EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0 ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000) Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000 00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289 Call Trace: [] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211] [] ath_attach+0x707/0x9e6 [ath9k] [] ath_pci_probe+0x18d/0x29a [ath9k] [] pci_device_probe+0xa3/0xe4 [] really_probe+0xd7/0x1de [] __driver_attach+0x37/0x55 [] bus_for_each_dev+0x31/0x57 [] driver_attach+0x16/0x18 [] bus_add_driver+0xec/0x21b [] driver_register+0x85/0xe2 [] __pci_register_driver+0x3c/0x69 [] ath9k_init+0x43/0x68 [ath9k] [] _stext+0x3b/0x116 [] sys_init_module+0x8a/0x19e [] sysenter_do_call+0x12/0x21 [] 0xffffe430 ======================= Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75 06 8b 35 c8 bb ec f8 a1 cc bb ec f8 <8b> 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6 8b EIP: [] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44 Cc: stable@kernel.org Reported-by: Nataraj Sadasivam Reported-by: Vivek Natarajan Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville --- net/wireless/reg.c | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'net') diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 6c1993d..3a73494 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -907,6 +907,7 @@ EXPORT_SYMBOL(freq_reg_info); int freq_reg_info(struct wiphy *wiphy, u32 center_freq, u32 *bandwidth, const struct ieee80211_reg_rule **reg_rule) { + assert_cfg80211_lock(); return freq_reg_info_regd(wiphy, center_freq, bandwidth, reg_rule, NULL); } @@ -1176,6 +1177,8 @@ static void handle_channel_custom(struct wiphy *wiphy, struct ieee80211_supported_band *sband; struct ieee80211_channel *chan; + assert_cfg80211_lock(); + sband = wiphy->bands[band]; BUG_ON(chan_idx >= sband->n_channels); chan = &sband->channels[chan_idx]; @@ -1214,10 +1217,13 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy, const struct ieee80211_regdomain *regd) { enum ieee80211_band band; + + mutex_lock(&cfg80211_mutex); for (band = 0; band < IEEE80211_NUM_BANDS; band++) { if (wiphy->bands[band]) handle_band_custom(wiphy, band, regd); } + mutex_unlock(&cfg80211_mutex); } EXPORT_SYMBOL(wiphy_apply_custom_regulatory); -- cgit v1.1 From b1ed8ddd21a2d7acf8efbb60a112ea5c9f914159 Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" Date: Sat, 2 May 2009 00:34:15 -0400 Subject: cfg80211: fix bug while trying to process beacon hints on init During initialization we would not have received any beacons so skip processing reg beacon hints, also adds a check to reg_is_world_roaming() for last_request before accessing its fields. This should fix this: BUG: unable to handle kernel NULL pointer dereference at IP: [] wiphy_update_regulatory+0x20f/0x295 *pdpt = 0000000008bf1001 *pde = 0000000000000000 Oops: 0000 [#1] last sysfs file: /sys/class/backlight/eeepc/brightness Modules linked in: ath5k(+) mac80211 led_class cfg80211 go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6 ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801 e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp re agpgart eeepc_laptop snd_page_alloc ac video backlight rfkill button processor evdev thermal fan ata_generic Pid: 2909, comm: modprobe Tainted: Pc #112) 701 EIP: 0060:[] EFLAGS: 00010246 CPU: 0 EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211] EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060 ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000) Stack: df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402 00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02 00000282 000080d0 00000068 c5d53500 00000080 0000028240 Call Trace: [] ? wiphy_register+0x122/0x1b7 [cfg80211] [] ? ieee80211_register_hw+0xd8/0x346 [] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k] [] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k] [] ? sysfs_find_dirent+0x16/0x27 [] ? local_pci_probe+0xe/0x10 [] ? pci_device_probe+0x48/0x66 [] ? driver_probe_device+0x7f/0xf2 [] ? __driver_attach+0x43/0x5f [] ? bus_for_each_dev+0x39/0x5a [] ? driver_attach+0x14/0x16 [] ? __driver_attach+0x0/0x5f [] ? bus_add_driver+0xd7/0x1e7 [] ? driver_register+0x7b/0xd7 [] ? __pci_register_driver+0x32/0x85 [] ? init_ath5k_pci+0x18/0x30 [ath5k] [] ? _stext+0x49/0x10b [] ? init_ath5k_pci+0x0/0x30 [ath5k] [] ? __blocking_notifier_call_chain+0x40/0x4c [] ? sys_init_module+0x87/0x18b [] ? sysenter_do_call+0x12/0x22 Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b 85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da 4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48 EIP: [] wiphy_update_regulatory+0x20f/0x295 SP 0068:df3bdd40 CR2: 0000000000000004 ---[ end trace 830f2dd2a95fd1a8 ]--- This issue is hard to reproduce, but it was noticed and discussed on this thread: http://marc.info/?t=123938022700005&r=1&w=2 Cc: stable@kernel.org Reported-by: Alan Jenkins Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville --- net/wireless/reg.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'net') diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 3a73494..974b127 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1134,7 +1134,8 @@ static bool reg_is_world_roaming(struct wiphy *wiphy) if (is_world_regdom(cfg80211_regdomain->alpha2) || (wiphy->regd && is_world_regdom(wiphy->regd->alpha2))) return true; - if (last_request->initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE && + if (last_request && + last_request->initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE && wiphy->custom_regulatory) return true; return false; @@ -1143,6 +1144,12 @@ static bool reg_is_world_roaming(struct wiphy *wiphy) /* Reap the advantages of previously found beacons */ static void reg_process_beacons(struct wiphy *wiphy) { + /* + * Means we are just firing up cfg80211, so no beacons would + * have been processed yet. + */ + if (!last_request) + return; if (!reg_is_world_roaming(wiphy)) return; wiphy_update_beacon_reg(wiphy); -- cgit v1.1 From 30a548c727514484b08ac06edf0a7eb0f7fd70bf Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" Date: Sat, 2 May 2009 01:17:27 -0400 Subject: cfg80211: fix comment on regulatory hint processing Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville --- net/wireless/reg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'net') diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 974b127..08265ca 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1436,7 +1436,7 @@ new_request: return call_crda(last_request->alpha2); } -/* This currently only processes user and driver regulatory hints */ +/* This processes *all* regulatory hints */ static void reg_process_hint(struct regulatory_request *reg_request) { int r = 0; -- cgit v1.1 From 8e532175277d9a5eae49768ed086555081f741a7 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 4 May 2009 18:04:55 +0200 Subject: mac80211: minstrel, fix memory corruption minstrel doesn't count max rate count in fact, since it doesn't use a loop variable `i' and hence allocs space only for bitrates found in the first band. Fix it by involving the `i' as an index so that it traverses all the bands now and finds the real max bitrate count. Signed-off-by: Jiri Slaby Cc: Felix Fietkau Signed-off-by: John W. Linville --- net/mac80211/rc80211_minstrel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'net') diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c index 3824990..70df3dc 100644 --- a/net/mac80211/rc80211_minstrel.c +++ b/net/mac80211/rc80211_minstrel.c @@ -476,7 +476,7 @@ minstrel_alloc_sta(void *priv, struct ieee80211_sta *sta, gfp_t gfp) return NULL; for (i = 0; i < IEEE80211_NUM_BANDS; i++) { - sband = hw->wiphy->bands[hw->conf.channel->band]; + sband = hw->wiphy->bands[i]; if (sband->n_bitrates > max_rates) max_rates = sband->n_bitrates; } -- cgit v1.1 From 6909268dc93ae4b0b8e1ebb4b2fa70b1a47dd347 Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 4 May 2009 18:10:28 +0200 Subject: mac80211: pid, fix memory corruption pid doesn't count with some band having more bitrates than the one associated the first time. Fix that by counting the maximal available bitrate count and allocate big enough space. Secondly, fix touching uninitialized memory which causes panics. Index sucked from this random memory points to the hell. The fix is to sort the rates on each band change. Signed-off-by: Jiri Slaby Signed-off-by: John W. Linville --- net/mac80211/rc80211_pid_algo.c | 73 ++++++++++++++++++++++------------------- 1 file changed, 39 insertions(+), 34 deletions(-) (limited to 'net') diff --git a/net/mac80211/rc80211_pid_algo.c b/net/mac80211/rc80211_pid_algo.c index b16801c..01d59a8 100644 --- a/net/mac80211/rc80211_pid_algo.c +++ b/net/mac80211/rc80211_pid_algo.c @@ -317,13 +317,44 @@ rate_control_pid_rate_init(void *priv, struct ieee80211_supported_band *sband, struct ieee80211_sta *sta, void *priv_sta) { struct rc_pid_sta_info *spinfo = priv_sta; + struct rc_pid_info *pinfo = priv; + struct rc_pid_rateinfo *rinfo = pinfo->rinfo; struct sta_info *si; + int i, j, tmp; + bool s; /* TODO: This routine should consider using RSSI from previous packets * as we need to have IEEE 802.1X auth succeed immediately after assoc.. * Until that method is implemented, we will use the lowest supported * rate as a workaround. */ + /* Sort the rates. This is optimized for the most common case (i.e. + * almost-sorted CCK+OFDM rates). Kind of bubble-sort with reversed + * mapping too. */ + for (i = 0; i < sband->n_bitrates; i++) { + rinfo[i].index = i; + rinfo[i].rev_index = i; + if (RC_PID_FAST_START) + rinfo[i].diff = 0; + else + rinfo[i].diff = i * pinfo->norm_offset; + } + for (i = 1; i < sband->n_bitrates; i++) { + s = 0; + for (j = 0; j < sband->n_bitrates - i; j++) + if (unlikely(sband->bitrates[rinfo[j].index].bitrate > + sband->bitrates[rinfo[j + 1].index].bitrate)) { + tmp = rinfo[j].index; + rinfo[j].index = rinfo[j + 1].index; + rinfo[j + 1].index = tmp; + rinfo[rinfo[j].index].rev_index = j; + rinfo[rinfo[j + 1].index].rev_index = j + 1; + s = 1; + } + if (!s) + break; + } + spinfo->txrate_idx = rate_lowest_index(sband, sta); /* HACK */ si = container_of(sta, struct sta_info, sta); @@ -336,21 +367,22 @@ static void *rate_control_pid_alloc(struct ieee80211_hw *hw, struct rc_pid_info *pinfo; struct rc_pid_rateinfo *rinfo; struct ieee80211_supported_band *sband; - int i, j, tmp; - bool s; + int i, max_rates = 0; #ifdef CONFIG_MAC80211_DEBUGFS struct rc_pid_debugfs_entries *de; #endif - sband = hw->wiphy->bands[hw->conf.channel->band]; - pinfo = kmalloc(sizeof(*pinfo), GFP_ATOMIC); if (!pinfo) return NULL; - /* We can safely assume that sband won't change unless we get - * reinitialized. */ - rinfo = kmalloc(sizeof(*rinfo) * sband->n_bitrates, GFP_ATOMIC); + for (i = 0; i < IEEE80211_NUM_BANDS; i++) { + sband = hw->wiphy->bands[i]; + if (sband->n_bitrates > max_rates) + max_rates = sband->n_bitrates; + } + + rinfo = kmalloc(sizeof(*rinfo) * max_rates, GFP_ATOMIC); if (!rinfo) { kfree(pinfo); return NULL; @@ -368,33 +400,6 @@ static void *rate_control_pid_alloc(struct ieee80211_hw *hw, pinfo->rinfo = rinfo; pinfo->oldrate = 0; - /* Sort the rates. This is optimized for the most common case (i.e. - * almost-sorted CCK+OFDM rates). Kind of bubble-sort with reversed - * mapping too. */ - for (i = 0; i < sband->n_bitrates; i++) { - rinfo[i].index = i; - rinfo[i].rev_index = i; - if (RC_PID_FAST_START) - rinfo[i].diff = 0; - else - rinfo[i].diff = i * pinfo->norm_offset; - } - for (i = 1; i < sband->n_bitrates; i++) { - s = 0; - for (j = 0; j < sband->n_bitrates - i; j++) - if (unlikely(sband->bitrates[rinfo[j].index].bitrate > - sband->bitrates[rinfo[j + 1].index].bitrate)) { - tmp = rinfo[j].index; - rinfo[j].index = rinfo[j + 1].index; - rinfo[j + 1].index = tmp; - rinfo[rinfo[j].index].rev_index = j; - rinfo[rinfo[j + 1].index].rev_index = j + 1; - s = 1; - } - if (!s) - break; - } - #ifdef CONFIG_MAC80211_DEBUGFS de = &pinfo->dentries; de->target = debugfs_create_u32("target_pf", S_IRUSR | S_IWUSR, -- cgit v1.1