kernel/git/stable/linux.git/net/mac80211, branch linux-2.6.35.y

mac80211: fix TKIP replay vulnerability

2011-08-01T20:55:03+00:00

[ upstream commit 34459512ffa7236c849466e3bd604801389734e1 ] 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). [AK: This was a non trivial backport. Johannes, John, please double check] Cc: stable@kernel.org Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Andi Kleen

mac80211: Restart STA timers only on associated state

2011-08-01T20:55:02+00:00

[ upstream commit 676b58c27475a9defccc025fea1cbd2b141ee539 ] 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. Cc: stable@kernel.org Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Andi Kleen

mac80211: initialize sta->last_rx in sta_info_alloc

2011-03-31T18:58:50+00:00

commit 8bc8aecdc5e26cfda12dbd6867af4aa67836da6a upstream. This field is used to determine the inactivity time. When in AP mode, hostapd uses it for kicking out inactive clients after a while. Without this patch, hostapd immediately deauthenticates a new client if it checks the inactivity time before the client sends its first data frame. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

mac80211: fix initialization of skb->cb in ieee80211_subif_start_xmit

2011-02-06T19:04:07+00:00

[ upstream commit 489ee9195a7de9e6bc833d639ff6b553ffdad90e ] The change 'mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs' added a check for copying the skb if it's shared, however the tx info variable still points at the cb of the old skb Signed-off-by: Felix Fietkau Acked-by: Helmut Schaa Signed-off-by: John W. Linville Signed-off-by: Andi Kleen

mac80211: fix mesh forwarding when ratelimited too

2011-02-06T19:04:07+00:00

[ upstream commit 919bbad580445801c22ef6ccbe624551fee652bd ] Commit b51aff057c9d0ef6c529dc25fd9f775faf7b6c63 said: Under memory pressure, the mac80211 mesh code may helpfully print a message that it failed to clone a mesh frame and then will proceed to crash trying to use it anyway. Fix that. Avoid the reference whenever the frame copy is unsuccessful regardless of the debug message being suppressed or printed. Cc: stable@kernel.org [2.6.27+] Signed-off-by: Milton Miller Signed-off-by: John W. Linville Signed-off-by: Andi Kleen

mac80211: fix hard lockup in sta_addba_resp_timer_expired

2011-02-06T19:03:53+00:00

Problem is 2.6.35 specific, bug was introduced in backport of upstream 44271488b91c9eecf249e075a1805dd887e222d2 commit. We can not call del_timer_sync(addba_resp_timer) from ___ieee80211_stop_tx_ba_session(), as this function can be called from that timer callback. To fix, simply use not synchronous del_timer(). Resolve https://bugzilla.redhat.com/show_bug.cgi?id=667459 Reported-and-tested-by: Mathieu Chouquet-Stringer Signed-off-by: Stanislaw Gruszka Signed-off-by: Andi Kleen

mac80211: fix mesh forwarding

2011-02-06T19:03:51+00:00

commit b51aff057c9d0ef6c529dc25fd9f775faf7b6c63 upstream. Under memory pressure, the mac80211 mesh code may helpfully print a message that it failed to clone a mesh frame and then will proceed to crash trying to use it anyway. Fix that. Signed-off-by: Johannes Berg Acked-by: Javier Cardona Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs

2011-02-06T19:03:31+00:00

commit 7e2447075690860e2cea96b119fc9cadbaa7e83c upstream. mac80211 doesn't handle shared skbs correctly at the moment. As a result a possible resize can trigger a BUG in pskb_expand_head. [ 676.030000] Kernel bug detected[#1]: [ 676.030000] Cpu 0 [ 676.030000] $ 0 : 00000000 00000000 819662ff 00000002 [ 676.030000] $ 4 : 81966200 00000020 00000000 00000020 [ 676.030000] $ 8 : 819662e0 800043c0 00000002 00020000 [ 676.030000] $12 : 3b9aca00 00000000 00000000 00470000 [ 676.030000] $16 : 80ea2000 00000000 00000000 00000000 [ 676.030000] $20 : 818aa200 80ea2018 80ea2000 00000008 [ 676.030000] $24 : 00000002 800ace5c [ 676.030000] $28 : 8199a000 8199bd20 81938f88 80f180d4 [ 676.030000] Hi : 0000026e [ 676.030000] Lo : 0000757e [ 676.030000] epc : 801245e4 pskb_expand_head+0x44/0x1d8 [ 676.030000] Not tainted [ 676.030000] ra : 80f180d4 ieee80211_skb_resize+0xb0/0x114 [mac80211] [ 676.030000] Status: 1000a403 KERNEL EXL IE [ 676.030000] Cause : 10800024 [ 676.030000] PrId : 0001964c (MIPS 24Kc) [ 676.030000] Modules linked in: mac80211_hwsim rt2800lib rt2x00soc rt2x00pci rt2x00lib mac80211 crc_itu_t crc_ccitt cfg80211 compat arc4 aes_generic deflate ecb cbc [last unloaded: rt2800pci] [ 676.030000] Process kpktgend_0 (pid: 97, threadinfo=8199a000, task=81879f48, tls=00000000) [ 676.030000] Stack : ffffffff 00000000 00000000 00000014 00000004 80ea2000 00000000 00000000 [ 676.030000] 818aa200 80f180d4 ffffffff 0000000a 81879f78 81879f48 81879f48 00000018 [ 676.030000] 81966246 80ea2000 818432e0 80f1a420 80203050 81814d98 00000001 81879f48 [ 676.030000] 81879f48 00000018 81966246 818432e0 0000001a 8199bdd4 0000001c 80f1b72c [ 676.030000] 80203020 8001292c 80ef4aa2 7f10b55d 801ab5b8 81879f48 00000188 80005c90 [ 676.030000] ... [ 676.030000] Call Trace: [ 676.030000] [<801245e4>] pskb_expand_head+0x44/0x1d8 [ 676.030000] [<80f180d4>] ieee80211_skb_resize+0xb0/0x114 [mac80211] [ 676.030000] [<80f1a420>] ieee80211_xmit+0x150/0x22c [mac80211] [ 676.030000] [<80f1b72c>] ieee80211_subif_start_xmit+0x6f4/0x73c [mac80211] [ 676.030000] [<8014361c>] pktgen_thread_worker+0xfac/0x16f8 [ 676.030000] [<8002ebe8>] kthread+0x7c/0x88 [ 676.030000] [<80008e0c>] kernel_thread_helper+0x10/0x18 [ 676.030000] [ 676.030000] [ 676.030000] Code: 24020001 10620005 2502001f <0200000d> 0804917a 00000000 2502001f 00441023 00531021 Fix this by making a local copy of shared skbs prior to mangeling them. To avoid copying the skb unnecessarily move the skb_copy call below the checks that don't need write access to the skb. Also, move the assignment of nh_pos and h_pos below the skb_copy to point to the correct skb. It would be possible to avoid another resize of the copied skb by using skb_copy_expand instead of skb_copy but that would make the patch more complex. Also, shared skbs are a corner case right now, so the resize shouldn't matter much. Cc: Johannes Berg Signed-off-by: Helmut Schaa Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

mac80211: delete AddBA response timer

2010-12-14T22:40:02+00:00

commit 44271488b91c9eecf249e075a1805dd887e222d2 upstream. We never delete the addBA response timer, which is typically fine, but if the station it belongs to is deleted very quickly after starting the BA session, before the peer had a chance to reply, the timer may fire after the station struct has been freed already. Therefore, we need to delete the timer in a suitable spot -- best when the session is being stopped (which will happen even then) in which case the delete will be a no-op most of the time. I've reproduced the scenario and tested the fix. This fixes the crash reported at http://mid.gmane.org/4CAB6F96.6090701@candelatech.com Reported-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

mac80211: don't sanitize invalid rates

2010-12-14T22:40:02+00:00

commit 5f4e6b2d3c74c1adda1cbfd9d9d30da22c7484fc upstream. I found this bug while poking around with a pure-gn AP. Commit: cfg80211/mac80211: Use more generic bitrate mask for rate control Added some sanity checks to ensure that each tx rate index is included in the configured mask and it would change any rate indexes if it wasn't. But, the current implementation doesn't take into account that the invalid rate index "-1" has a special meaning (= no further attempts) and it should not be "changed". Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen