Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: jouni=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A620AC433CA
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
Message-Id: <20201214172118.18100-1-jouni@codeaurora.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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