summaryrefslogtreecommitdiff
path: root/arch/x86/Makefile.um
diff options
context:
space:
mode:
authorJouni Malinen <j@w1.fi>2020-01-07 18:35:45 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-02-05 16:05:50 +0300
commita98051bb43a742fe89732caa2e7a15dae17fcf9a (patch)
tree74e9a0802ad2942064955ece71f433738d51c111 /arch/x86/Makefile.um
parent71616d42fc1ab8686898c3cf060bc0751dbbe0cb (diff)
downloadlinux-a98051bb43a742fe89732caa2e7a15dae17fcf9a.tar.xz
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>
Diffstat (limited to 'arch/x86/Makefile.um')
0 files changed, 0 insertions, 0 deletions