From patchwork Thu Sep 28 14:35:39 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Greenman, Gregory" X-Patchwork-Id: 13403190 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9D99E732E0 for ; Thu, 28 Sep 2023 14:36:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231534AbjI1Ogj (ORCPT ); Thu, 28 Sep 2023 10:36:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231596AbjI1Ogh (ORCPT ); Thu, 28 Sep 2023 10:36:37 -0400 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80E0A136 for ; Thu, 28 Sep 2023 07:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695911796; x=1727447796; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ua4ZGso1xaLXHXSvTBiuX2m7cSG81XStHJwmvnLVE9A=; b=A3+R0Z/9mUl1flaXFHQuOgMGtrL+aKkyuBJ0lFNkm1PqAG0JliogReEY 325cYx1bUn5NcHHxMR+svzeMvCNX26IzkwQzs9nam4hrwg08pKK9q7BvC hnklCSYMY1ksDoH2nfuc3Xa8eTUGVK8aSa4go/VpDpfRxvF80R7cwxyXi KTc33WHZ1+ldRD57fppyqbCoP7LYtpP+AbqFQxV6OVUF0/M54cHkqHFwp UFdjya6vkeYO+/yBBit2vIKsheTCnAIJ6Z30FN+i1XvwDqmZf3EvmsTZU Lb15qGU1eu0rd1EEhOqtzSLJtEyY6oCZeskG8cQkcPUQKwaAUqvJlOSoi A==; X-IronPort-AV: E=McAfee;i="6600,9927,10847"; a="688554" X-IronPort-AV: E=Sophos;i="6.03,184,1694761200"; d="scan'208";a="688554" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2023 07:36:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10847"; a="996590579" X-IronPort-AV: E=Sophos;i="6.03,184,1694761200"; d="scan'208";a="996590579" Received: from smoriles-mobl1.ger.corp.intel.com (HELO ggreenma-mobl2.intel.com) ([10.249.92.89]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2023 07:36:33 -0700 From: gregory.greenman@intel.com To: johannes@sipsolutions.net Cc: linux-wireless@vger.kernel.org, Johannes Berg , Gregory Greenman Subject: [PATCH 18/18] wifi: mac80211: flush STA queues on unauthorization Date: Thu, 28 Sep 2023 17:35:39 +0300 Message-Id: <20230928172905.d47f528829e7.I96903652c7ee0c5c66891f8b2364383da8e45a1f@changeid> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230928143539.1037500-1-gregory.greenman@intel.com> References: <20230928143539.1037500-1-gregory.greenman@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org From: Johannes Berg When the station is marked as no longer authorized, we shouldn't transmit to it any longer, but in particular we shouldn't be able to transmit to it after removing keys, which might lead to frames being sent out unencrypted depending on the exact hardware offload mechanism. Thus, instead of flushing only on station destruction, which covers only some cases, always flush on unauthorization. Signed-off-by: Johannes Berg Signed-off-by: Gregory Greenman --- net/mac80211/sta_info.c | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c index 450700173422..0ba613dd1cc4 100644 --- a/net/mac80211/sta_info.c +++ b/net/mac80211/sta_info.c @@ -1275,6 +1275,8 @@ static int _sta_info_move_state(struct sta_info *sta, enum ieee80211_sta_state new_state, bool recalc) { + struct ieee80211_local *local = sta->local; + might_sleep(); if (sta->sta_state == new_state) @@ -1350,6 +1352,24 @@ static int _sta_info_move_state(struct sta_info *sta, } else if (sta->sta_state == IEEE80211_STA_AUTHORIZED) { ieee80211_vif_dec_num_mcast(sta->sdata); clear_bit(WLAN_STA_AUTHORIZED, &sta->_flags); + + /* + * If we have encryption offload, flush (station) queues + * (after ensuring concurrent TX completed) so we won't + * transmit anything later unencrypted if/when keys are + * also removed, which might otherwise happen depending + * on how the hardware offload works. + */ + if (local->ops->set_key) { + synchronize_net(); + if (local->ops->flush_sta) + drv_flush_sta(local, sta->sdata, sta); + else + ieee80211_flush_queues(local, + sta->sdata, + false); + } + ieee80211_clear_fast_xmit(sta); ieee80211_clear_fast_rx(sta); } @@ -1415,18 +1435,6 @@ static void __sta_info_destroy_part2(struct sta_info *sta, bool recalc) WARN_ON_ONCE(ret); } - /* Flush queues before removing keys, as that might remove them - * from hardware, and then depending on the offload method, any - * frames sitting on hardware queues might be sent out without - * any encryption at all. - */ - if (local->ops->set_key) { - if (local->ops->flush_sta) - drv_flush_sta(local, sta->sdata, sta); - else - ieee80211_flush_queues(local, sta->sdata, false); - } - /* now keys can no longer be reached */ ieee80211_free_sta_keys(local, sta);