linux-toradex.git/net/wireless, branch v2.6.30-rc7

cfg80211: fix comment on regulatory hint processing

2009-05-04T20:22:14+00:00

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

cfg80211: fix bug while trying to process beacon hints on init

2009-05-04T20:22:13+00:00

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

cfg80211: fix race condition with wiphy_apply_custom_regulatory()

2009-05-04T20:22:12+00:00

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

cfg80211: fix truncated IEs

2009-05-04T20:22:10+00:00

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

nl80211: Make nl80211_send_mlme_event() atomic

2009-04-20T20:36:26+00:00

One of the code paths sending deauth/disassoc events ends up calling
this function with rcu_read_lock held, so we must use GFP_ATOMIC in
allocation routines.

Reported-by: Johannes Berg 
Signed-off-by: Jouni Malinen 
Signed-off-by: John W. Linville

cfg80211: do not replace BSS structs

2009-04-17T19:27:13+00:00

Instead, allocate extra IE memory if necessary. Normally,
this isn't even necessary since there's enough space.

This is a better way of correcting the "held BSS can
disappear" issue, but also a lot more code. It is also
necessary for proper auth/assoc BSS handling in the
future.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: copy hold when replacing BSS

2009-04-17T19:27:13+00:00

When we receive a probe response frame we can replace the
BSS struct in our list -- but if that struct is held then
we need to hold the new one as well.

We really should fix this completely and not replace the
struct, but this is a bandaid for now.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix NULL pointer deference in reg_device_remove()

2009-04-16T14:39:01+00:00

We won't ever get here as regulatory_hint_core() can only fail
on -ENOMEM and in that case we don't initialize cfg80211 but this is
technically correct code.

This is actually good for stable, where we don't check for -ENOMEM
failure on __regulatory_hint()'s failure.

Cc: stable@kernel.org
Reported-by: Quentin Armitage 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

cfg80211: default CONFIG_WIRELESS_OLD_REGULATORY to n

2009-03-28T00:13:23+00:00

And update description and feature-removal schedule according
to the new plan.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

cfg80211: fix locking in nl80211_set_wiphy

2009-03-28T00:13:20+00:00

Luis reports that there's a circular locking dependency;
this is because cfg80211_dev_rename() will acquire the
cfg80211_mutex while the device mutex is held, while
this normally is done the other way around. The solution
is to open-code the device-getting in nl80211_set_wiphy
and require holding the mutex around cfg80211_dev_rename
rather than acquiring it within.

Also fix a bug -- rtnl locking is expected by drivers so
we need to provide it.

Reported-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville