[PATCH AUTOSEL 6.19-6.6] wifi: iwlwifi: mvm: check the validity of noa_len

[Sasha Levin <sashal@kernel.org>]

From: Miri Korenblit <miriam.rachel.korenblit@intel.com>

[ Upstream commit 1e3fb3c4a8e6c581d0f4533dba887fabf53d607d ]

Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using
its value to determine the noa_len, which is later used for the NoA
attribute.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e1160b9b94fa8be44e67bcc1b9@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good, `IWL_FW_CHECK` is defined and available.

### 7. Summary

**What the fix does**: Adds input validation for the `len_low` field in
NoA (Notice of Absence) attribute data received from Intel Wi-Fi
firmware. Before this fix, an invalid `len_low` value would result in
incorrect `noa_len` calculation, which is subsequently used in
`skb_put()` and `memcpy()` operations when constructing probe response
frames.

**Why it matters**: Without this validation, malformed firmware data
could lead to incorrect frame construction, potentially transmitting
malformed or garbage-containing P2P frames over the air. This is a
defensive validation fix — small, surgical, and zero risk of regression
since valid firmware data will pass the check unaffected.

**Stable criteria assessment**:
- Obviously correct: Yes — the validation logic is straightforward
  (len_low must match one of two known valid values)
- Fixes a real bug: Yes — invalid firmware data leads to incorrect NoA
  length computation used in memcpy
- Small and contained: Yes — 14 lines added in one file, single
  validation check
- No new features: Correct — pure input validation
- Risk: Extremely low — early return on invalid input cannot affect
  valid paths

**YES** — This is a small, surgical input validation fix that prevents
processing invalid firmware data. It meets all stable kernel criteria:
it's obviously correct, fixes a real potential bug (incorrect buffer
lengths derived from unvalidated firmware input), is small and self-
contained, and has near-zero regression risk.

**YES**

 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 867807abde664..49ffc4ecee855 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -1761,6 +1761,20 @@ void iwl_mvm_probe_resp_data_notif(struct iwl_mvm *mvm,
 
 	mvmvif = iwl_mvm_vif_from_mac80211(vif);
 
+	/*
+	 * len_low should be 2 + n*13 (where n is the number of descriptors.
+	 * 13 is the size of a NoA descriptor). We can have either one or two
+	 * descriptors.
+	 */
+	if (IWL_FW_CHECK(mvm, notif->noa_active &&
+			 notif->noa_attr.len_low != 2 +
+			 sizeof(struct ieee80211_p2p_noa_desc) &&
+			 notif->noa_attr.len_low != 2 +
+			 sizeof(struct ieee80211_p2p_noa_desc) * 2,
+			 "Invalid noa_attr.len_low (%d)\n",
+			 notif->noa_attr.len_low))
+		return;
+
 	new_data = kzalloc(sizeof(*new_data), GFP_KERNEL);
 	if (!new_data)
 		return;
-- 
2.51.0