linux-stable.git/net/mac80211, branch v3.0.9

mac80211: disable powersave for broken APs

2011-11-11T17:37:13+00:00

commit 05cb91085760ca378f28fc274fbf77fc4fd9886c upstream.

Only AID values 1-2007 are valid, but some APs have been
found to send random bogus values, in the reported case an
AP that was sending the AID field value 0xffff, an AID of
0x3fff (16383).

There isn't much we can do but disable powersave since
there's no way it can work properly in this case.

Reported-by: Bill C Riemers 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: config hw when going back on-channel

2011-11-11T17:37:12+00:00

commit 6911bf0453e0d6ea8eb694a4ce67a68d071c538e upstream.

When going back on-channel, we should reconfigure
the hw iff the hardware is not already configured
to the operational channel.

Signed-off-by: Eliad Peller 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix remain_off_channel regression

2011-11-11T17:37:12+00:00

commit eaa7af2ae582c9a8c51b374c48d5970b748a5ce2 upstream.

The offchannel code is currently broken - we should
remain_off_channel if the work was started, and
the work's channel and channel_type are the same
as local->tmp_channel and local->tmp_channel_type.

However, if wk->chan_type and local->tmp_channel_type
coexist (e.g. have the same channel type), we won't
remain_off_channel.

This behavior was introduced by commit da2fd1f
("mac80211: Allow work items to use existing
channel type.")

Tested-by: Ben Greear 
Signed-off-by: Eliad Peller 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix offchannel TX cookie matching

2011-11-11T17:35:51+00:00

commit 28a1bcdb57d50f3038a255741ecc83e391e5282e upstream.

When I introduced in-kernel off-channel TX I
introduced a bug -- the work can't be canceled
again because the code clear the skb pointer.
Fix this by keeping track separately of whether
TX status has already been reported.

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

mac80211: fix missing sta_lock in __sta_info_destroy

2011-10-03T18:40:28+00:00

commit 4bae7d976976fa52d345805ba686934cd548343e upstream.

Since my commit 34e895075e21be3e21e71d6317440d1ee7969ad0
("mac80211: allow station add/remove to sleep") there is
a race in mac80211 when it clears the TIM bit because a
sleeping station disconnected, the spinlock isn't held
around the relevant code any more. Use the right API to
acquire the spinlock correctly.

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

net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared

2011-08-16T01:31:38+00:00

[ Upstream commit 550fd08c2cebad61c548def135f67aba284c6162 ]

After the last patch, We are left in a state in which only drivers calling
ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
hardware call ether_setup for their net_devices and don't hold any state in
their skbs.  There are a handful of drivers that violate this assumption of
course, and need to be fixed up.  This patch identifies those drivers, and marks
them as not being able to support the safe transmission of skbs by clearning the
IFF_TX_SKB_SHARING flag in priv_flags

Signed-off-by: Neil Horman 
CC: Karsten Keil 
CC: "David S. Miller" 
CC: Jay Vosburgh 
CC: Andy Gospodarek 
CC: Patrick McHardy 
CC: Krzysztof Halasa 
CC: "John W. Linville" 
CC: Greg Kroah-Hartman 
CC: Marcel Holtmann 
CC: Johannes Berg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mac80211: Restart STA timers only on associated state

2011-08-05T04:58:35+00:00

commit 676b58c27475a9defccc025fea1cbd2b141ee539 upstream.

A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.

Signed-off-by: Rajkumar Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix TKIP replay vulnerability

2011-07-07T17:06:09+00:00

Unlike CCMP, the presence or absence of the QoS
field doesn't change the encryption, only the
TID is used. When no QoS field is present, zero
is used as the TID value. This means that it is
possible for an attacker to take a QoS packet
with TID 0 and replay it as a non-QoS packet.

Unfortunately, mac80211 uses different IVs for
checking the validity of the packet's TKIP IV
when it checks TID 0 and when it checks non-QoS
packets. This means it is vulnerable to this
replay attack.

To fix this, use the same replay counter for
TID 0 and non-QoS packets by overriding the
rx->queue value to 0 if it is 16 (non-QoS).

This is a minimal fix for now. I caused this
issue in

commit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a
Author: Johannes Berg 
Date:   Thu Jul 10 10:11:02 2008 +0200

    mac80211: fix RX sequence number check

while fixing a sequence number issue (there,
a separate counter needs to be used).

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

mac80211: fix ie memory allocation for scheduled scans

2011-07-07T17:06:08+00:00

We were not allocating memory for the IEs passed in the scheduled_scan
request and this was causing memory corruption (buffer overflow).

Signed-off-by: Luciano Coelho 
Signed-off-by: John W. Linville

mac80211: fix rx->key NULL dereference during mic failure

2011-06-27T18:45:25+00:00

Sometimes when reporting a MIC failure rx->key may be unset. This
code path is hit when receiving a packet meant for a multicast
address, and decryption is performed in HW.

Fortunately, the failing key_idx is not used for anything up to
(and including) usermode, so we allow ourselves to drop it on the
way up when a key cannot be retrieved.

Signed-off-by: Arik Nemtsov 
Cc: stable@kernel.org
Signed-off-by: John W. Linville