From: Jouni Malinen <jouni@codeaurora.org>
To: ath9k-devel@qca.qualcomm.com, kvalo@codeaurora.org
Cc: linux-wireless@vger.kernel.org, Jouni Malinen <jouni@codeaurora.org>
Subject: [PATCH 0/5] ath9k: Safer key deletion to avoid unexpected behavior
Date: Mon, 14 Dec 2020 19:21:13 +0200 [thread overview]
Message-ID: <20201214172118.18100-1-jouni@codeaurora.org> (raw)
While earlier mac80211 commits like a0761a301746 ("mac80211: drop data
frames without key on encrypted links"), ce2e1ca70307 ("mac80211: Check
port authorization in the ieee80211_tx_dequeue() case"), and
b16798f5b907 ("mac80211: mark station unauthorized before key removal")
addressed the most visible and easiest to trigger cases where pending
frames from TX queues could potentially end up getting transmitted
without proper encryption, some similar cases could still remain in the
hardware TX queue. In such cases, clearing of the hardware key cache
entry could happen while there were remaining frames in the TX queues
with reference to the deleted key. That could end up transmitting such
frames without encryption. These issues are related to CVE-2020-3702.
It is not clear whether this can be triggered in the station mode after
the mac80211 changes, but it has been possible to come up with a test
setup where this could be triggered in the AP mode where the TX queue is
shared with multiple destinations and cannot be flushed when a single
station disconnects. Address such cases by not clearing the hardware key
cache entry immediately, but instead, temporarily leaving the key in
place and disabling RX processing for the key cache entry. Such a
postponed key deletion is completed once there are no remaining frames
referencing the particular key cache entry. This is done before handling
the next key cache operation to avoid having to perform heavy operations
during normal TX operations.
Jouni Malinen (5):
ath: Use safer key clearing with key cache entries
ath9k: Clear key cache explicitly on disabling hardware
ath: Export ath_hw_keysetmac()
ath: Modify ath_key_delete() to not need full key entry
ath9k: Postpone key cache entry deletion for TXQ frames reference it
drivers/net/wireless/ath/ath.h | 3 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 95 ++++++++++++++++++-
drivers/net/wireless/ath/key.c | 41 ++++----
6 files changed, 122 insertions(+), 22 deletions(-)
--
2.20.1
next reply other threads:[~2020-12-14 17:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-14 17:21 Jouni Malinen [this message]
2020-12-14 17:21 ` [PATCH 1/5] ath: Use safer key clearing with key cache entries Jouni Malinen
2020-12-17 6:51 ` Kalle Valo
2020-12-17 9:40 ` Pali Rohár
2020-12-17 16:06 ` Kalle Valo
2020-12-28 21:35 ` Pali Rohár
2021-01-11 8:01 ` Kalle Valo
2020-12-14 17:21 ` [PATCH 2/5] ath9k: Clear key cache explicitly on disabling hardware Jouni Malinen
2020-12-14 17:21 ` [PATCH 3/5] ath: Export ath_hw_keysetmac() Jouni Malinen
2020-12-14 17:21 ` [PATCH 4/5] ath: Modify ath_key_delete() to not need full key entry Jouni Malinen
2020-12-14 17:21 ` [PATCH 5/5] ath9k: Postpone key cache entry deletion for TXQ frames reference it Jouni Malinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201214172118.18100-1-jouni@codeaurora.org \
--to=jouni@codeaurora.org \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).