linux-toradex.git/net/mac80211/wpa.c, branch v3.0.22

mac80211: fix rx->key NULL pointer dereference in promiscuous mode

2012-01-26T01:24:43+00:00

commit 1140afa862842ac3e56678693050760edc4ecde9 upstream.

Since:

commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
Author: Christian Lamparter 
Date:   Sat Apr 30 15:24:30 2011 +0200

    mac80211: consolidate MIC failure report handling

is possible to that we dereference rx->key == NULL when driver set
RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
promiscuous mode. This happen with rt73usb and rt61pci at least.

Before the commit we always check rx->key against NULL, so I assume
fix should be done in mac80211 (also mic_fail path has similar check).

References:
https://bugzilla.redhat.com/show_bug.cgi?id=769766
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html

Reported-by: Stuart D Gathman 
Reported-by: Kai Wohlfahrt 
Signed-off-by: Stanislaw Gruszka 
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 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

mac80211: consolidate MIC failure report handling

2011-05-02T18:49:14+00:00

Currently, mac80211 handles MIC failures differently
depending on whenever they are detected by the stack's
own software crypto or when are handed down from the
driver.

This patch tries to unify both by moving the special
branch out of mac80211 rx hotpath and into into the
software crypto part. This has the advantage that we
can run a few more sanity checks on the data and verify
if the key type was TKIP. This is very handy because
several devices generate false postive MIC failure
reports. Like carl9170, ath9k and wl12xx:

"mac80211: report MIC failure for truncated packets in AP mode"

Cc: Luciano Coelho 
Cc: Arik Nemtsov 
Signed-off-by: Christian Lamparter 
Signed-off-by: John W. Linville

mac80211: Add testing functionality for TKIP

2011-02-03T21:45:29+00:00

TKIP countermeasures depend on devices being able to detect Michael
MIC failures on received frames and for stations to report errors to
the AP. In order to test that behavior, it is useful to be able to
send out TKIP frames with incorrect Michael MIC. This testing behavior
has minimal effect on the TX path, so it can be added to mac80211 for
convenient use.

The interface for using this functionality is a file in mac80211
netdev debugfs (tkip_mic_test). Writing a MAC address to the file
makes mac80211 generate a dummy data frame that will be sent out using
invalid Michael MIC value. In AP mode, the address needs to be for one
of the associated stations or ff:ff:ff:ff:ff:ff to use a broadcast
frame. In station mode, the address can be anything, e.g., the current
BSSID. It should be noted that this functionality works correctly only
when associated and using TKIP.

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

mac80211: Remove obsolete TKIP flexibility

2011-02-03T21:45:29+00:00

The TKIP implementation was originally prepared to be a bit more
flexible in the way Michael MIC TX/RX keys are configured. However, we
are now taking care of the TX/RX MIC key swapping in user space, so
this code will not be needed. Similarly, there were some remaining WPA
testing code that won't be used in their current form. Remove the
unneeded extra complexity.

Signed-off-by: Jouni Malinen 
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: move packet flags into packet

2010-09-27T19:57:54+00:00

commit 8c0c709eea5cbab97fb464cd68b06f24acc58ee1
Author: Johannes Berg 
Date:   Wed Nov 25 17:46:15 2009 +0100

    mac80211: move cmntr flag out of rx flags

moved the CMNTR flag into the skb RX flags for
some aggregation cleanups, but this was wrong
since the optimisation this flag tried to make
requires that it is kept across the processing
of multiple interfaces -- which isn't true for
flags in the skb. The patch not only broke the
optimisation, it also introduced a bug: under
some (common!) circumstances the flag will be
set on an already freed skb!

However, investigating this in more detail, I
found that most of the flags that we set should
be per packet, _except_ for this one, due to
a-MPDU processing. Additionally, the flags used
for processing (currently just this one) need
to be reset before processing a new packet.

Since we haven't actually seen bugs reported as
a result of the wrong flags handling (which is
not too surprising -- the only real bug case I
can come up with is an a-MSDU contained in an
a-MPDU), I'll make a different fix for rc.

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

mac80211: remove unused status flag checks

2010-08-16T20:45:21+00:00

The decryption code verifies whether or not
a given frame was decrypted and verified by
hardware. This is unnecessary, as the crypto
RX handler already does it long before the
decryption code is even invoked, so remove
that code to avoid confusion.

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

mac80211: use cipher suite selectors

2010-08-16T20:45:11+00:00

Currently, mac80211 translates the cfg80211
cipher suite selectors into ALG_* values.
That isn't all too useful, and some drivers
benefit from the distinction between WEP40
and WEP104 as well. Therefore, convert it
all to use the cipher suite selectors.

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

mac80211: remove wep dependency

2010-07-08T20:35:50+00:00

The current mac80211 code assumes that WEP is always available.  If WEP
fails to initialize, ieee80211_register_hw will always fail.

In some cases (e.g. FIPS certification), the cryptography used by WEP is
unavailable.  However, in such cases there is no good reason why CCMP
encryption (or even no link level encryption) cannot be used.  So, this
patch removes mac80211's assumption that WEP (and TKIP) will always be
available for use.

Signed-off-by: John W. Linville