ath9k: Safer key deletion to avoid unexpected behavior
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 5 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | ath: Use safer key clearing with key cache entriesdrivers/ | +10 | 5 replies | |
| 2/5 | ath9k: Clear key cache explicitly on disabling hardwaredrivers/ | +5 | 0 replies | |
| 3/5 | ath: Export ath_hw_keysetmac()drivers/ drivers/ | +3 | 0 replies | |
| 4/5 | ath: Modify ath_key_delete() to not need full key entrydrivers/ drivers/ drivers/ +2 more | +22 | 0 replies | |
| 5/5 | ath9k: Postpone key cache entry deletion for TXQ frames reference itdrivers/ drivers/ | +87 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] ath9k: Safer key deletion to avoid unexpected behavior
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(-)
Signature · 1 line
2.20.1