linux-kernel - [PATCH AUTOSEL 6.10 109/121] wifi: iwlwifi: mvm: don't send an ROC command with max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240801000834.3930818-109-sashal@kernel.org>
Date: Wed, 31 Jul 2024 20:00:47 -0400
From: Sasha Levin <sashal@...nel.org>
To: linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Cc: Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
	Miri Korenblit <miriam.rachel.korenblit@...el.com>,
	Johannes Berg <johannes.berg@...el.com>,
	Sasha Levin <sashal@...nel.org>,
	kvalo@...nel.org,
	gregory.greenman@...el.com,
	shaul.triebitz@...el.com,
	quic_adisi@...cinc.com,
	linux-wireless@...r.kernel.org
Subject: [PATCH AUTOSEL 6.10 109/121] wifi: iwlwifi: mvm: don't send an ROC command with max_delay = 0

From: Emmanuel Grumbach <emmanuel.grumbach@...el.com>

[ Upstream commit 187accaa328dc4de98064eef176841b8a4716f96 ]

The firmware can't handle that (it will crash with ASSERT 300A).
This happened because we looked at vif->bss_conf which is not
the right bss_conf to look at in case of an MLD connection.
Fix iwl_mvm_roc_duration_and_delay to iterate on the active links to
get the right value for the dtim_interval.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@...el.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@...el.com>
Reviewed-by: Johannes Berg <johannes.berg@...el.com>
Link: https://patch.msgid.link/20240703064027.e12f8d84c8fd.I3dd9f720c678c06ec7a5bf7ca56e21cf0b614c8c@changeid
Signed-off-by: Johannes Berg <johannes.berg@...el.com>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
 .../net/wireless/intel/iwlwifi/mvm/time-event.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
index 31bc80cdcb7d5..97cfd72312f2f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
@@ -984,12 +984,21 @@ void iwl_mvm_roc_duration_and_delay(struct ieee80211_vif *vif,
 				    u32 *duration_tu,
 				    u32 *delay)
 {
-	u32 dtim_interval = vif->bss_conf.dtim_period *
-		vif->bss_conf.beacon_int;
+	struct ieee80211_bss_conf *link_conf;
+	unsigned int link_id;
+	u32 dtim_interval = 0;
 
 	*delay = AUX_ROC_MIN_DELAY;
 	*duration_tu = MSEC_TO_TU(duration_ms);
 
+	rcu_read_lock();
+	for_each_vif_active_link(vif, link_conf, link_id) {
+		dtim_interval =
+			max_t(u32, dtim_interval,
+			      link_conf->dtim_period * link_conf->beacon_int);
+	}
+	rcu_read_unlock();
+
 	/*
 	 * If we are associated we want the delay time to be at least one
 	 * dtim interval so that the FW can wait until after the DTIM and
@@ -998,8 +1007,10 @@ void iwl_mvm_roc_duration_and_delay(struct ieee80211_vif *vif,
 	 * Since we want to use almost a whole dtim interval we would also
 	 * like the delay to be for 2-3 dtim intervals, in case there are
 	 * other time events with higher priority.
+	 * dtim_interval should never be 0, it can be 1 if we don't know it
+	 * (we haven't heard any beacon yet).
 	 */
-	if (vif->cfg.assoc) {
+	if (vif->cfg.assoc && !WARN_ON(!dtim_interval)) {
 		*delay = min_t(u32, dtim_interval * 3, AUX_ROC_MAX_DELAY);
 		/* We cannot remain off-channel longer than the DTIM interval */
 		if (dtim_interval <= *duration_tu) {
-- 
2.43.0