linux-stable.git/net/mac80211, branch linux-2.6.31.y

mac80211: Fix bug in computing crc over dynamic IEs in beacon

2009-12-18T21:43:44+00:00

commit 1814077fd12a9cdf478c10076e9c42094e9d9250 upstream.

On a 32-bit machine, BIT() macro does not give the required
bit value if the bit is mroe than 31. In ieee802_11_parse_elems_crc(),
BIT() is suppossed to get the bit value more than 31 (42 (id of ERP_INFO_IE),
37 (CHANNEL_SWITCH_IE), (42), 32 (POWER_CONSTRAINT_IE), 45 (HT_CAP_IE),
61 (HT_INFO_IE)). As we do not get the required bit value for the above
IEs, crc over these IEs are never calculated, so any dynamic change in these
IEs after the association is not really handled on 32-bit platforms.
This patch fixes this issue.

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix spurious delBA handling

2009-12-08T18:21:44+00:00

commit 827d42c9ac91ddd728e4f4a31fefb906ef2ceff7 upstream.

Lennert Buytenhek noticed that delBA handling in mac80211
was broken and has remotely triggerable problems, some of
which are due to some code shuffling I did that ended up
changing the order in which things were done -- this was

  commit d75636ef9c1af224f1097941879d5a8db7cd04e5
  Author: Johannes Berg 
  Date:   Tue Feb 10 21:25:53 2009 +0100

    mac80211: RX aggregation: clean up stop session

and other parts were already present in the original

  commit d92684e66091c0f0101819619b315b4bb8b5bcc5
  Author: Ron Rindjunsky 
  Date:   Mon Jan 28 14:07:22 2008 +0200

      mac80211: A-MPDU Tx add delBA from recipient support

The first problem is that I moved a BUG_ON before various
checks -- thereby making it possible to hit. As the comment
indicates, the BUG_ON can be removed since the ampdu_action
callback must already exist when the state is != IDLE.

The second problem isn't easily exploitable but there's a
race condition due to unconditionally setting the state to
OPERATIONAL when a delBA frame is received, even when no
aggregation session was ever initiated. All the drivers
accept stopping the session even then, but that opens a
race window where crashes could happen before the driver
accepts it. Right now, a WARN_ON may happen with non-HT
drivers, while the race opens only for HT drivers.

For this case, there are two things necessary to fix it:
 1) don't process spurious delBA frames, and be more careful
    about the session state; don't drop the lock

 2) HT drivers need to be prepared to handle a session stop
    even before the session was really started -- this is
    true for all drivers (that support aggregation) but
    iwlwifi which can be fixed easily. The other HT drivers
    (ath9k and ar9170) are behaving properly already.

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

mac80211: fix two remote exploits

2009-12-08T18:21:42+00:00

commit 4253119acf412fd686ef4bd8749b5a4d70ea3a51 upstream.

Lennert Buytenhek noticed a remotely triggerable problem
in mac80211, which is due to some code shuffling I did
that ended up changing the order in which things were
done -- this was in

  commit d75636ef9c1af224f1097941879d5a8db7cd04e5
  Author: Johannes Berg 
  Date:   Tue Feb 10 21:25:53 2009 +0100

    mac80211: RX aggregation: clean up stop session

The problem is that the BUG_ON moved before the various
checks, and as such can be triggered.

As the comment indicates, the BUG_ON can be removed since
the ampdu_action callback must already exist when the
state is OPERATIONAL.

A similar code path leads to a WARN_ON in
ieee80211_stop_tx_ba_session, which can also be removed.

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

mac80211: check interface is down before type change

2009-11-10T00:22:31+00:00

commit c1f9a764cf47686b1f5a0cf87ada68d90056136a upstream.

For some strange reason the netif_running() check
ended up after the actual type change instead of
before, potentially causing all kinds of problems
if the interface is up while changing the type;
one of the problems manifests itself as a warning:

WARNING: at net/mac80211/iface.c:651 ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]()
Hardware name: Aspire one
Pid: 2596, comm: wpa_supplicant Tainted: G        W  2.6.31-10-generic #32-Ubuntu
Call Trace:
 [] warn_slowpath_common+0x6d/0xa0
 [] warn_slowpath_null+0x15/0x20
 [] ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]
 [] ieee80211_if_change_type+0x4a/0xc0 [mac80211]
 [] ieee80211_change_iface+0x61/0xa0 [mac80211]
 [] cfg80211_wext_siwmode+0xc7/0x120 [cfg80211]
 [] ioctl_standard_call+0x58/0xf0

(http://www.kerneloops.org/searchweek.php?search=ieee80211_teardown_sdata)

Cc: Arjan van de Ven 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix for incorrect sequence number on hostapd injected frames

2009-11-10T00:22:30+00:00

commit 9b1ce526eb917c8b5c8497c327768130ee683392 upstream.

When hostapd injects a frame, e.g. an authentication or association
response, mac80211 looks for a suitable access point virtual interface
to associate the frame with based on its source address. This makes it
possible e.g. to correctly assign sequence numbers to the frames.

A small typo in the ethernet address comparison statement caused a
failure to find a suitable ap interface. Sequence numbers on such
frames where therefore left unassigned causing some clients
(especially windows-based 11b/g clients) to reject them and fail to
authenticate or associate with the access point. This patch fixes the
typo in the address comparison statement.

Signed-off-by: Björn Smedman 
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix vlan and optimise RX

2009-10-22T22:12:01+00:00

commit fbc44bf7177dfd61381da55405550b693943a432 upstream.

When receiving data frames, we can send them only to
the interface they belong to based on transmitting
station (this doesn't work for probe requests). Also,
don't try to handle other frames for AP_VLAN at all
since those interface should only receive data.

Additionally, the transmit side must check that the
station we're sending a frame to is actually on the
interface we're transmitting on, and not transmit
packets to functions that live on other interfaces,
so validate that as well.

Another bug fix is needed in sta_info.c where in the
VLAN case when adding/removing stations we overwrite
the sdata variable we still need.

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

mac80211: fix todo lock

2009-08-17T17:38:34+00:00

The key todo lock can be taken from different locks
that require it to be _bh to avoid lock inversion
due to (soft)irqs.

This should fix the two problems reported by Bob and
Gabor:
http://mid.gmane.org/20090619113049.GB18956@hash.localnet
http://mid.gmane.org/4A3FA376.8020307@openwrt.org

Signed-off-by: Johannes Berg 
Cc: Bob Copeland 
Cc: Gabor Juhos 
Signed-off-by: John W. Linville

mac80211: fix panic when splicing unprepared TIDs

2009-08-13T18:47:42+00:00

We splice skbs from the pending queue for a TID
onto the local pending queue when tearing down a
block ack request. This is not necessary unless we
actually have received a request to start a block ack
request (rate control, for example). If we never received
that request we should not be splicing the tid pending
queue as it would be null, causing a panic.

Not sure yet how exactly we allowed through a call when the
tid state does not have at least HT_ADDBA_REQUESTED_MSK set,
that will require some further review as it is not quite
obvious.

For more information see the bug report:

http://bugzilla.kernel.org/show_bug.cgi?id=13922

This fixes this oops:

BUG: unable to handle kernel NULL pointer dereference at 00000030
IP: [] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211]
*pdpt = 0000000002d1e001 *pde = 0000000000000000
Thread overran stack, or stack corrupted
Oops: 0000 [#1] SMP
last sysfs file: /sys/module/aes_generic/initstate
Modules linked in: 

Pid: 0, comm: swapper Not tainted (2.6.31-rc5-wl #2) Dell DV051
EIP: 0060:[] EFLAGS: 00010292 CPU: 0
EIP is at ieee80211_agg_splice_packets+0x40/0xc0 [mac80211]
EAX: 00000030 EBX: 0000004c ECX: 00000003 EDX: 00000000
ESI: c1c98000 EDI: f745a1c0 EBP: c076be58 ESP: c076be38
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c076a000 task=c0709160 task.ti=c076a000)
Stack: 
Call Trace:
 [] ? ieee80211_stop_tx_ba_cb+0xab/0x150 [mac80211]
 [] ? ieee80211_tasklet_handler+0xce/0x110 [mac80211]
 [] ? net_rx_action+0xef/0x1d0
 [] ? tasklet_action+0x58/0xc0
 [] ? __do_softirq+0xc2/0x190
 [] ? handle_IRQ_event+0x58/0x140
 [] ? ack_apic_level+0x7e/0x270
 [] ? do_softirq+0x3d/0x40
 [] ? irq_exit+0x65/0x90
 [] ? do_IRQ+0x4f/0xc0
 [] ? irq_exit+0x7d/0x90
 [] ? smp_apic_timer_interrupt+0x57/0x90
 [] ? common_interrupt+0x29/0x30
 [] ? mwait_idle+0xbe/0x100
 [] ? cpu_idle+0x52/0x90
 [] ? rest_init+0x55/0x60
 [] ? start_kernel+0x315/0x37d
 [] ? unknown_bootoption+0x0/0x1f9
 [] ? i386_start_kernel+0x79/0x81
Code: 
EIP: [] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211] SS:ESP 0068:c076be38
CR2: 0000000000000030

Cc: stable@kernel.org
Testedy-by: Jack Lau 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

mac80211: fix suspend

2009-07-29T18:52:01+00:00

Jan reported that his b43-based laptop hangs during suspend.
The problem turned out to be mac80211 asking the driver to
stop the hardware before removing interfaces, and interface
removal caused b43 to touch the hardware (while down, which
causes the hang).

This patch fixes mac80211 to do reorder these operations to
have them in the correct order -- first remove interfaces
and then stop the hardware. Some more code is necessary to
be able to do so in a race-free manner, in particular it is
necessary to not process frames received during quiescing.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13337.

Reported-by: Jan Scholz 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: do not queue work after suspend in the dynamic ps timer

2009-07-27T19:19:38+00:00

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