kernel.git/net/mac80211/rx.c, branch linux-3.7.y

mac80211: make sure data is accessible in EAPOL check

2012-10-26T20:52:42Z

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. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg

mac80211: verify that skb data is present

2012-10-26T20:52:42Z

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. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg

mac80211: check management frame header length

2012-10-26T20:52:41Z

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. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg

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

2012-10-25T19:54:41Z

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. Cc: stable@vger.kernel.org Signed-off-by: Javier Cardona Signed-off-by: Javier Lopez Signed-off-by: Johannes Berg

mac80211: Don't drop frames received with mesh ttl == 1

2012-10-25T11:52:20Z

Prior this fix, those frames were not received, nor forwarded. Fix this to receive and not forward. Signed-off-by: Javier Cardona Signed-off-by: Johannes Berg

mac80211: Only process mesh config header on frames that RA_MATCH

2012-10-25T11:51:29Z

Doing otherwise is wrong, and may wreak havoc on the mpp tables, specially if the frame is encrypted. Cc: stable@vger.kernel.org Reported-by: Chaoxing Lin Signed-off-by: Javier Cardona Signed-off-by: Johannes Berg

mac80211: don't use kerneldoc for ieee80211_add_rx_radiotap_header

2012-09-05T13:55:27Z

Doing so creates warnings, but the function is internal and not part of the 802.11 docbooks, so it from kerneldoc. Signed-off-by: Johannes Berg

mac80211: use RX status band instead of current band

2012-08-20T12:13:43Z

Even for single-channel devices it is possible that we switch the channel temporarily (e.g. for scanning) but while doing so process a received frame that was still received on the old channel, so checking the current band is racy. Use the band from status instead. Signed-off-by: Johannes Berg

mac80211: support P2P Device abstraction

2012-08-20T11:58:22Z

After cfg80211 got a P2P Device abstraction, add support to mac80211. Whether it really is supported or not will depend on whether or not the driver has support for it, but mac80211 needs to change to be able to support drivers that need a P2P Device. Signed-off-by: Johannes Berg

mac80211: support A-MPDU status reporting

2012-08-20T11:53:22Z

Support getting A-MPDU status information from the drivers and reporting it to userspace via radiotap in the standard fields. Signed-off-by: Johannes Berg