diff options
author | David Bauer <mail@david-bauer.net> | 2020-04-16 21:30:27 +0200 |
---|---|---|
committer | David Bauer <mail@david-bauer.net> | 2020-04-17 13:27:40 +0200 |
commit | 0f1b5ce2f5d07c1358f2da417133cd18e62fd9b9 (patch) | |
tree | 6b92ebf1305865e07e54541b59b2787e2bf0c20f /package/boot/uboot-imx6/Makefile | |
parent | 8918c038f330a1bb5a898d80c170caf9f42cac89 (diff) | |
download | upstream-0f1b5ce2f5d07c1358f2da417133cd18e62fd9b9.tar.gz upstream-0f1b5ce2f5d07c1358f2da417133cd18e62fd9b9.tar.bz2 upstream-0f1b5ce2f5d07c1358f2da417133cd18e62fd9b9.zip |
mac80211: drop data frames without key on encrypted links
If we know that we have an encrypted link (based on having had
a key configured for TX in the past) then drop all data frames
in the key selection handler if there's no key anymore.
This fixes an issue with mac80211 internal TXQs - there we can
buffer frames for an encrypted link, but then if the key is no
longer there when they're dequeued, the frames are sent without
encryption. This happens if a station is disconnected while the
frames are still on the TXQ.
Detecting that a link should be encrypted based on a first key
having been configured for TX is fine as there are no use cases
for a connection going from with encryption to no encryption.
With extended key IDs, however, there is a case of having a key
configured for only decryption, so we can't just trigger this
behaviour on a key being configured.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
Diffstat (limited to 'package/boot/uboot-imx6/Makefile')
0 files changed, 0 insertions, 0 deletions