mac80211: Fix TKIP replay protection immediately after key setup
authorJouni Malinen <j@w1.fi>
Tue, 7 Jan 2020 15:35:45 +0000 (17:35 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 5 Feb 2020 14:43:46 +0000 (14:43 +0000)
commitd3f51f28574a2b1888d910d30c7a5e7c250d0062
tree7a3ae090d918bf09475d0098896731d5a87f47f0
parenta4f85674e4693904ade7cbf6722d0d105d8062d8
mac80211: Fix TKIP replay protection immediately after key setup

[ Upstream commit 6f601265215a421f425ba3a4850a35861d024643 ]

TKIP replay protection was skipped for the very first frame received
after a new key is configured. While this is potentially needed to avoid
dropping a frame in some cases, this does leave a window for replay
attacks with group-addressed frames at the station side. Any earlier
frame sent by the AP using the same key would be accepted as a valid
frame and the internal RSC would then be updated to the TSC from that
frame. This would allow multiple previously transmitted group-addressed
frames to be replayed until the next valid new group-addressed frame
from the AP is received by the station.

Fix this by limiting the no-replay-protection exception to apply only
for the case where TSC=0, i.e., when this is for the very first frame
protected using the new key, and the local RSC had not been set to a
higher value when configuring the key (which may happen with GTK).

Signed-off-by: Jouni Malinen <j@w1.fi>
Link: https://lore.kernel.org/r/20200107153545.10934-1-j@w1.fi
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/mac80211/tkip.c