CVSROOT: /cvs
Module name: src
Changes by: s...@cvs.openbsd.org 2020/05/15 08:21:09
Modified files:
sys/dev/ic : ar5008.c
sys/dev/pci : if_iwn.c if_wpi.c
sys/net80211 : ieee80211_crypto.c ieee80211_crypto.h
ieee80211_crypto_ccmp.c ieee80211_crypto_tkip.c
ieee80211_input.c
Log message:
Fix CCMP replay check with 11n Rx aggregation and CCMP hardware offloading.
So far, drivers using hardware CCMP decryption were expected to keep the
most recently seen CCMP packet number (PN) up-to-date, and to discard frames
with lower PNs as replays.
A-MPDU subframes may legitimately arrive out of order, and the drivers skipped
CCMP replay checking for such frames. Re-ordering happens in ieee80211_inputm(),
after the driver is done with a frame. Drivers cannot tell replayed frames
apart from legitimate out-of-order retransmissions.
To fix this, update the PN value in ieee80211_inputm() after subframes have
been reordered into their proper sequence. Drivers still perform replay checks
but they no longer have to worry about updating the last seen PN value.
The 802.11 spec confirms that replay checking is supposed to happen after
A-MPDU re-ordering.
Tested by jmc@, benno@, solene@, and myself with the following drivers:
athn(4), iwn(4), iwm(4), wpi(4), urtwn(4)
ok solene@
