linux-stable.git/net/wireless, branch linux-2.6.35.y

nl80211: fix check for valid SSID size in scan operations

2011-08-01T20:54:55+00:00

commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03 upstream.

In both trigger_scan and sched_scan operations, we were checking for
the SSID length before assigning the value correctly.  Since the
memory was just kzalloc'ed, the check was always failing and SSID with
over 32 characters were allowed to go through.

This was causing a buffer overflow when copying the actual SSID to the
proper place.

This bug has been there since 2.6.29-rc4.

Signed-off-by: Luciano Coelho 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

cfg80211: fix can_beacon_sec_chan, reenable HT40

2011-03-31T18:58:52+00:00

[ upstream commit 09a02fdb919876c01e8f05960750a418b3f7fa48 ]

This follows wireless-testing 9236d838c920e90708570d9bbd7bb82d30a38130
("cfg80211: fix extension channel checks to initiate communication") and
fixes accidental case fall-through. Without this fix, HT40 is entirely
blocked.

Signed-off-by: Mark Mentovai 
Signed-off-by: Andi Kleen 
Cc: stable@kernel.org
Acked-by: Luis R. Rodriguez

cfg80211: fix extension channel checks to initiate communication

2010-12-14T22:40:18+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 
Signed-off-by: Andi Kleen

cfg80211: fix regression on processing country IEs

2010-12-14T22:40:01+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.
[AK: it seems to be needed for .35 too?? Kept for now]

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

cfg80211: fix locking

2010-12-14T22:40:00+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 
Signed-off-by: Andi Kleen

cfg80211: fix BSS double-unlinking

2010-12-14T22:40:00+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 
Signed-off-by: Andi Kleen

wext: fix potential private ioctl memory content leak

2010-10-29T04:51:27+00:00

commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream.

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 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

wireless extensions: fix kernel heap content leak

2010-09-20T20:36:42+00:00

commit 42da2f948d949efd0111309f5827bf0298bcc9a4 upstream.

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).

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

cfg80211: fix locking in action frame TX

2010-08-26T23:45:48+00:00

commit fe100acddf438591ecf3582cb57241e560da70b7 upstream.

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

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

cfg80211: don't get expired BSSes

2010-08-10T18:09:20+00:00

commit ccb6c1360f8dd43303c659db718e7e0b24175db5 upstream.

When kernel-internal users use cfg80211_get_bss()
to get a reference to a BSS struct, they may end
up getting one that would have been removed from
the list if there had been any userspace access
to the list. This leads to inconsistencies and
problems.

Fix it by making cfg80211_get_bss() ignore BSSes
that cfg80211_bss_expire() would remove.

Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180

Reported-by: Jiajia Zheng 
Tested-by: Jiajia Zheng 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman