linux-toradex.git/net/wireless, branch tegra-10.11.7

cfg80211: fix extension channel checks to initiate communication

2010-12-09T21:33:33+00:00

commit 9236d838c920e90708570d9bbd7bb82d30a38130 upstream.

When operating in a mode that initiates communication and using
HT40 we should fail if we cannot use both primary and secondary
channels to initiate communication. Our current ht40 allowmap
only covers STA mode of operation, for beaconing modes we need
a check on the fly as the mode of operation is dynamic and
there other flags other than disable which we should read
to check if we can initiate communication.

Do not allow for initiating communication if our secondary HT40
channel has is either disabled, has a passive scan flag, a
no-ibss flag or is a radar channel. Userspace now has similar
checks but this is also needed in-kernel.

Reported-by: Jouni Malinen 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix regression on processing country IEs

2010-12-09T21:32:07+00:00

commit a171fba491f54216e356efa46096171a7ed01d10 upstream.

The patch 4f366c5:

	wireless: only use alpha2 regulatory information from country IE

removed some complex intersection we were always doing between the AP's
country IE info and what we got from CRDA. When CRDA sent us back a
regulatory domain we would do some sanity checks on that regulatory
domain response we just got. Part of these sanity checks included
checking that we already had performed an intersection for the
request of NL80211_REGDOM_SET_BY_COUNTRY_IE type.

This mean that cfg80211 was only processing country IEs for cases
where we already had an intersection, but since we removed enforcing
this this is no longer required, we should just apply the country
IE country hint with the data received from CRDA.

This patch has fixes intended for kernels >= 2.6.36.

Reported-by: Easwar Krishnan 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix locking

2010-12-09T21:32:07+00:00

commit 2234362c427e2ef667595b9b81c0125003ac5607 upstream.

Add missing unlocking of the wiphy in set_channel,
and don't try to unlock a non-existing wiphy in
set_cqm.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix BSS double-unlinking

2010-12-09T21:32:06+00:00

commit 3207390a8b58bfc1335750f91cf6783c48ca19ca upstream.

When multiple interfaces are actively trying
to associate with the same BSS, they may both
find that the BSS isn't there and then try to
unlink it. This can cause errors since the
unlinking code can't currently deal with items
that have already been unlinked.

Normally this doesn't happen as most people
don't try to use multiple station interfaces
that associate at the same time too.

Fix this by using the list entry as a flag to
see if the item is still on a list.

Reported-by: Ben Greear 
Tested-by: Hun-Kyi Wynn 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

wext: fix potential private ioctl memory content leak

2010-09-20T17:41:40+00:00

When a driver doesn't fill the entire buffer, old
heap contents may remain, and if it also doesn't
update the length properly, this old heap content
will be copied back to userspace.

It is very unlikely that this happens in any of
the drivers using private ioctls since it would
show up as junk being reported by iwpriv, but it
seems better to be safe here, so use kzalloc.

Reported-by: Jeff Mahoney 
Cc: stable@kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

wireless: register wiphy rfkill w/o holding cfg80211_mutex

2010-08-31T18:48:47+00:00

Otherwise lockdep complains...

https://bugzilla.kernel.org/show_bug.cgi?id=17311

[ INFO: possible circular locking dependency detected ]
2.6.36-rc2-git4 #12
-------------------------------------------------------
kworker/0:3/3630 is trying to acquire lock:
 (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x14

but task is already holding lock:
 (rfkill_global_mutex){+.+.+.}, at: []
rfkill_switch_all+0x24/0x49 [rfkill]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (rfkill_global_mutex){+.+.+.}:
       [] lock_acquire+0x120/0x15b
       [] __mutex_lock_common+0x54/0x52e
       [] mutex_lock_nested+0x34/0x39
       [] rfkill_register+0x2b/0x29c [rfkill]
       [] wiphy_register+0x1ae/0x270 [cfg80211]
       [] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
       [] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
       [] request_firmware_work_func+0x54/0x6f
       [] kthread+0x8c/0x94
       [] kernel_thread_helper+0x4/0x10

-> #1 (cfg80211_mutex){+.+.+.}:
       [] lock_acquire+0x120/0x15b
       [] __mutex_lock_common+0x54/0x52e
       [] mutex_lock_nested+0x34/0x39
       [] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
       [] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
       [] ioctl_standard_iw_point+0x1a8/0x272
       [] ioctl_standard_call+0x91/0xa7
       [] T.723+0xbd/0x12c
       [] wext_handle_ioctl+0x31/0x6d
       [] dev_ioctl+0x63d/0x67a
       [] sock_ioctl+0x48/0x21d
       [] do_vfs_ioctl+0x4ba/0x509
       [] sys_ioctl+0x51/0x74
       [] system_call_fastpath+0x16/0x1b

-> #0 (rtnl_mutex){+.+.+.}:
       [] __lock_acquire+0xa93/0xd9a
       [] lock_acquire+0x120/0x15b
       [] __mutex_lock_common+0x54/0x52e
       [] mutex_lock_nested+0x34/0x39
       [] rtnl_lock+0x12/0x14
       [] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
       [] rfkill_set_block+0x80/0xd5 [rfkill]
       [] __rfkill_switch_all+0x3f/0x6f [rfkill]
       [] rfkill_switch_all+0x38/0x49 [rfkill]
       [] rfkill_op_handler+0x105/0x136 [rfkill]
       [] process_one_work+0x248/0x403
       [] worker_thread+0x139/0x214
       [] kthread+0x8c/0x94
       [] kernel_thread_helper+0x4/0x10

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

wireless extensions: fix kernel heap content leak

2010-08-30T20:35:17+00:00

Wireless extensions have an unfortunate, undocumented
requirement which requires drivers to always fill
iwp->length when returning a successful status. When
a driver doesn't do this, it leads to a kernel heap
content leak when userspace offers a larger buffer
than would have been necessary.

Arguably, this is a driver bug, as it should, if it
returns 0, fill iwp->length, even if it separately
indicated that the buffer contents was not valid.

However, we can also at least avoid the memory content
leak if the driver doesn't do this by setting the iwp
length to max_tokens, which then reflects how big the
buffer is that the driver may fill, regardless of how
big the userspace buffer is.

To illustrate the point, this patch also fixes a
corresponding cfg80211 bug (since this requirement
isn't documented nor was ever pointed out by anyone
during code review, I don't trust all drivers nor
all cfg80211 handlers to implement it correctly).

Cc: stable@kernel.org [all the way back]
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix locking in action frame TX

2010-08-09T19:18:57+00:00

Accesses to "wdev->current_bss" must be
locked with the wdev lock, which action
frame transmission is missing.

Cc: stable@kernel.org [2.6.33+]
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: Update of regulatory request initiator handling

2010-07-28T20:24:01+00:00

In some cases there could be possible dereferencing freed pointer. The
update is intended to avoid this issue.

Signed-off-by: Yuri Ershov 
Signed-off-by: John W. Linville

nl80211: Fix memory leaks

2010-07-28T20:24:01+00:00

In case of errors during message composing msg should be freed after canceling.

Signed-off-by: Yuri Kululin 
Signed-off-by: Yuri Ershov 
Signed-off-by: John W. Linville