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

mac80211: make sure data is accessible in EAPOL check

2012-11-16T16:46:58+00:00

commit 6dbda2d00d466225f9db1dc695ff852443f28832 upstream.

The code to allow EAPOL frames even when the station
isn't yet marked associated needs to check that the
incoming frame is long enough and due to paged RX it
also can't assume skb->data contains the right data,
it must use skb_copy_bits(). Fix this to avoid using
data that doesn't really exist.

Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: verify that skb data is present

2012-11-16T16:46:58+00:00

commit 9b395bc3be1cebf0144a127c7e67d56dbdac0930 upstream.

A number of places in the mesh code don't check that
the frame data is present and in the skb header when
trying to access. Add those checks and the necessary
pskb_may_pull() calls. This prevents accessing data
that doesn't actually exist.

To do this, export ieee80211_get_mesh_hdrlen() to be
able to use it in mac80211.

Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: check management frame header length

2012-11-16T16:46:58+00:00

commit 4a4f1a5808c8bb0b72a4f6e5904c53fb8c9cd966 upstream.

Due to pskb_may_pull() checking the skb length, all
non-management frames are checked on input whether
their 802.11 header is fully present. Also add that
check for management frames and remove a check that
is now duplicate. This prevents accessing skb data
beyond the frame end.

Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: fix SSID copy on IBSS JOIN

2012-11-16T16:46:57+00:00

commit badecb001a310408d3473b1fc2ed5aefd0bc92a9 upstream.

The 'ssid' field of the cfg80211_ibss_params is a u8 pointer and
its length is likely to be less than IEEE80211_MAX_SSID_LEN most
of the time.

This patch fixes the ssid copy in ieee80211_ibss_join() by using
the SSID length to prevent it from reading beyond the string.

Signed-off-by: Antonio Quartulli 
[rewrapped commit message, small rewording]
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: don't inspect Sequence Control field on control frames

2012-11-16T16:46:56+00:00

commit f7fbf70ee9db6da6033ae50d100e017ac1f26555 upstream.

Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is
not present in control frames.  We noticed this problem when processing
Block Ack Requests.

Signed-off-by: Javier Cardona 
Signed-off-by: Javier Lopez 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: Only process mesh config header on frames that RA_MATCH

2012-11-16T16:46:56+00:00

commit 555cb715be8ef98b8ec362b23dfc254d432a35b1 upstream.

Doing otherwise is wrong, and may wreak havoc on the mpp tables,
specially if the frame is encrypted.

Reported-by: Chaoxing Lin 
Signed-off-by: Javier Cardona 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2: we have a large block conditional on
 IEEE80211_RX_RA_MATCH rather than a goto conditional on the opposite,
 so delete the condition]
Signed-off-by: Ben Hutchings

mac80211: check if key has TKIP type before updating IV

2012-10-30T23:26:46+00:00

commit 4045f72bcf3c293c7c5932ef001742d8bb5ded76 upstream.

This patch fix corruption which can manifest itself by following crash
when switching on rfkill switch with rt2x00 driver:
https://bugzilla.redhat.com/attachment.cgi?id=615362

Pointer key->u.ccmp.tfm of group key get corrupted in:

ieee80211_rx_h_michael_mic_verify():

        /* update IV in key information to be able to detect replays */
        rx->key->u.tkip.rx[rx->security_idx].iv32 = rx->tkip_iv32;
        rx->key->u.tkip.rx[rx->security_idx].iv16 = rx->tkip_iv16;

because rt2x00 always set RX_FLAG_MMIC_STRIPPED, even if key is not TKIP.

We already check type of the key in different path in
ieee80211_rx_h_michael_mic_verify() function, so adding additional
check here is reasonable.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

mac80211: cancel mesh path timer

2012-08-19T17:15:28+00:00

commit dd4c9260e7f23f2e951cbfb2726e468c6d30306c upstream.

The mesh path timer needs to be canceled when
leaving the mesh as otherwise it could fire
after the interface has been removed already.

Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: correct behaviour on unrecognised action frames

2012-07-12T03:32:03+00:00

commit 4b5ebccc40843104d980f0714bc86bfcd5568941 upstream.

When receiving an "individually addressed" action frame, the
receiver is required to return it to the sender. mac80211
gets this wrong as it also returns group addressed (mcast)
frames to the sender. Fix this and update the reference to
the new 802.11 standards version since things were shuffled
around significantly.

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

mac80211: clean up remain-on-channel on interface stop

2012-06-19T22:18:11+00:00

commit 71ecfa1893034eeb1c93e02e22ee2ad26d080858 upstream.

When any interface goes down, it could be the one that we
were doing a remain-on-channel with. We therefore need to
cancel the remain-on-channel and flush the related work
structs so they don't run after the interface has been
removed or even destroyed.

It's also possible in this case that an off-channel SKB
was never transmitted, so free it if this is the case.
Note that this can also happen if the driver finishes
the off-channel period without ever starting it.

Reported-by: Nirav Shah 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings