diff options
author | Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> | 2012-08-10 11:00:24 +0200 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2012-08-13 15:17:24 -0400 |
commit | e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 (patch) | |
tree | 9c36e5390402a18ba243b504895010b9dd214ebf /tools/hv | |
parent | e19f15ac6437624b6214b2f0ec0d69fb7eb205fa (diff) | |
download | op-kernel-dev-e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77.zip op-kernel-dev-e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77.tar.gz |
ath9k: fix decrypt_error initialization in ath_rx_tasklet()
ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
in a loop over the received frames. The decrypt_error flag is
initialized to false
just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
ath9k_rx_skb_preprocess(),
only sets decrypt_error to true and never to false.
Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
decrypt_error to it.
So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
have a leftover value
from another processed frame. In that case, the frame will not be marked with
RX_FLAG_DECRYPTED even if it is decrypted correctly.
When using CCMP encryption this issue can lead to connection stuck
because of CCMP
PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
deciphered frame with ieee80211_aes_ccm_decrypt.
Fix the issue initializing decrypt_error flag at the begging of the
ath_rx_tasklet() loop.
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'tools/hv')
0 files changed, 0 insertions, 0 deletions