user/sven/linux.git/net/wireless, branch v3.0.17

cfg80211: amend regulatory NULL dereference fix

2011-12-09T16:52:45Z

commit 0bac71af6e66dc798bf07d0c0dd14ee5503362f9 upstream. Johannes' patch for "cfg80211: fix regulatory NULL dereference" broke user regulaotry hints and it did not address the fact that last_request was left populated even if the previous regulatory hint was stale due to the wiphy disappearing. Fix user reguluatory hints by only bailing out if for those regulatory hints where a request_wiphy is expected. The stale last_request considerations are addressed through the previous fixes on last_request where we reset the last_request to a static world regdom request upon reset_regdomains(). In this case though we further enhance the effect by simply restoring reguluatory settings completely. Cc: Johannes Berg Signed-off-by: Luis R. Rodriguez Reviewed-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: fix race on init and driver registration

2011-12-09T16:52:45Z

commit a042994dd377d86bff9446ee76151ceb6267c9ba upstream. There is a theoretical race that if hit will trigger a crash. The race is between when we issue the first regulatory hint, regulatory_hint_core(), gets processed by the workqueue and between when the first device gets registered to the wireless core. This is not easy to reproduce but it was easy to do so through the regulatory simulator I have been working on. This is a port of the fix I implemented there [1]. [1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8 Cc: Johannes Berg Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: fix regulatory NULL dereference

2011-12-09T16:52:32Z

commit de3584bd62d87b4c250129fbc46ca52c80330add upstream. By the time userspace returns with a response to the regulatory domain request, the wiphy causing the request might have gone away. If this is so, reject the update but mark the request as having been processed anyway. Cc: Luis R. Rodriguez Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

nl80211: fix MAC address validation

2011-12-09T16:52:31Z

commit e007b857e88097c96c45620bf3b04a4e309053d1 upstream. MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Signed-off-by: Eliad Peller Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: fix bug on regulatory core exit on access to last_request

2011-11-26T17:09:55Z

commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream. Commit 4d9d88d1 by Scott James Remnant added the .uevent() callback for the regulatory device used during the platform device registration. The change was done to account for queuing up udev change requests through udevadm triggers. The change also meant that upon regulatory core exit we will now send a uevent() but the uevent() callback, reg_device_uevent(), also accessed last_request. Right before commiting device suicide we free'd last_request but never set it to NULL so platform_device_unregister() would lead to bogus kernel paging request. Fix this and also simply supress uevents right before we commit suicide as they are pointless. This fix is required for kernels >= v2.6.39 $ git describe --contains 4d9d88d1 v2.6.39-rc1~468^2~25^2^2~21 The impact of not having this present is that a bogus paging access may occur (only read) upon cfg80211 unload time. You may also get this BUG complaint below. Although Johannes could not reproduce the issue this fix is theoretically correct. mac80211_hwsim: unregister radios mac80211_hwsim: closing netlink BUG: unable to handle kernel paging request at ffff88001a06b5ab IP: [] reg_device_uevent+0x1a/0x50 [cfg80211] PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU 0 Modules linked in: cfg80211(-) [last unloaded: mac80211] Pid: 2279, comm: rmmod Tainted: G W 3.1.0-wl+ #663 Bochs Bochs RIP: 0010:[] [] reg_device_uevent+0x1a/0x50 [cfg80211] RSP: 0000:ffff88001c5f9d58 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0 RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0 R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001 FS: 00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780) Stack: ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189 Call Trace: [] dev_uevent+0xc5/0x170 [] kobject_uevent_env+0x1f7/0x490 [] ? sub_preempt_count+0x29/0x60 [] ? _raw_spin_unlock_irqrestore+0x4a/0x90 [] ? devres_release_all+0x27/0x60 [] kobject_uevent+0xb/0x10 [] device_del+0x157/0x1b0 [] platform_device_del+0x1d/0x90 [] platform_device_unregister+0x16/0x30 [] regulatory_exit+0x5d/0x180 [cfg80211] [] cfg80211_exit+0x2b/0x45 [cfg80211] [] sys_delete_module+0x16c/0x220 [] ? trace_hardirqs_on_caller+0x7e/0x120 [] system_call_fastpath+0x16/0x1b Code: RIP [] reg_device_uevent+0x1a/0x50 [cfg80211] RSP CR2: ffff88001a06b5ab ---[ end trace 147c5099a411e8c0 ]--- Reported-by: Johannes Berg Cc: Scott James Remnant Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

nl80211: fix HT capability attribute validation

2011-11-26T17:09:55Z

commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream. Since the NL80211_ATTR_HT_CAPABILITY attribute is used as a struct, it needs a minimum, not maximum length. Enforce that properly. Not doing so could potentially lead to reading after the buffer. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: Fix validation of AKM suites

2011-10-03T18:41:10Z

commit 1b9ca0272ffae212e726380f66777b30a56ed7a5 upstream. Incorrect variable was used in validating the akm_suites array from NL80211_ATTR_AKM_SUITES. In addition, there was no explicit validation of the array length (we only have room for NL80211_MAX_NR_AKM_SUITES). This can result in a buffer write overflow for stack variables with arbitrary data from user space. The nl80211 commands using the affected functionality require GENL_ADMIN_PERM, so this is only exposed to admin users. Signed-off-by: Jouni Malinen Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wireless: Reset beacon_found while updating regulatory

2011-10-03T18:40:40Z

commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream. During the association, the regulatory is updated by country IE that reaps the previously found beacons. The impact is that after a STA disconnects *or* when for any reason a regulatory domain change happens the beacon hint flag is not cleared therefore preventing future beacon hints to be learned. This is important as a regulatory domain change or a restore of regulatory settings would set back the passive scan and no-ibss flags on the channel. This is the right place to do this given that it covers any regulatory domain change. Reviewed-by: Luis R. Rodriguez Signed-off-by: Rajkumar Manoharan Acked-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: really ignore the regulatory request

2011-08-05T04:58:41Z

commit a203c2aa4cefccb879c879b8e1cad1a09a679e55 upstream. At the beginning of wiphy_update_regulatory() a check is performed whether the request is to be ignored. Then the request is sent to the driver nevertheless. This happens even if last_request points to NULL, leading to a crash in the driver: [] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [] (wiphy_update_regulatory+0x4d0/0x4f4) [] (wiphy_update_regulatory+0x4d0/0x4f4) from [] (wiphy_register+0x354/0x420) [] (wiphy_register+0x354/0x420) from [] (lbs_cfg_register+0x80/0x164 [libertas]) [] (lbs_cfg_register+0x80/0x164 [libertas]) from [] (lbs_start_card+0x20/0x88 [libertas]) [] (lbs_start_card+0x20/0x88 [libertas]) from [] (if_sdio_probe+0x898/0x9c0 [libertas_sdio]) Fix this by returning early. Also remove the out: label as it is not any longer needed. Signed-off-by: Sven Neumann Cc: linux-wireless@vger.kernel.org Cc: Johannes Berg Cc: Daniel Mack Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex

2011-07-05T18:42:36Z

There was a deadlock when rfkill-blocking a wireless interface, because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop sched_scans that were eventually running. The rfkill block code was already holding a mutex under rdev: kernel: ======================================================= kernel: [ INFO: possible circular locking dependency detected ] kernel: 3.0.0-rc1-00049-g1fa7b6a #57 kernel: ------------------------------------------------------- kernel: kworker/0:1/4525 is trying to acquire lock: kernel: (&rdev->mtx){+.+.+.}, at: [] cfg80211_netdev_notifier_call+0x131/0x5b0 kernel: kernel: but task is already holding lock: kernel: (&rdev->devlist_mtx){+.+.+.}, at: [] cfg80211_rfkill_set_block+0x4f/0xa0 kernel: kernel: which lock already depends on the new lock. To fix this, add a new mutex specifically for sched_scan, to protect the sched_scan_req element in the rdev struct, instead of using the global rdev mutex. Reported-by: Duane Griffin Signed-off-by: Luciano Coelho Signed-off-by: John W. Linville