[PATCH AUTOSEL 6.19-6.18] wifi: iwlwifi: mld: Handle rate selection for NAN interface

[Sasha Levin <sashal@kernel.org>]

From: Ilan Peer <ilan.peer@intel.com>

[ Upstream commit dbbeebece03050cd510073ce89fee83844e06b00 ]

Frames transmitted over a NAN interface might not have channel
information assigned to them. In such cases assign the lowest
OFDM to the frame.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251110180612.72046f98f878.Ib784931fffd0747acd9d7bb22eabbbec5282733e@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit addresses frames transmitted over a NAN (Neighbor Awareness
Networking) interface that might not have channel information assigned.
Without channel info, the `band` variable remains uninitialized or set
to an invalid value, which would lead to an out-of-bounds array access
when used as an index into `mld->hw->wiphy->bands[band]`.

### Code Change Analysis

The fix is a small, surgical addition of 4 lines (plus a blank line) in
`iwl_mld_get_lowest_rate()`:

```c
if (band >= NUM_NL80211_BANDS) {
    WARN_ON(vif->type != NL80211_IFTYPE_NAN);
    return IWL_FIRST_OFDM_RATE;
}
```

**What happens without this fix:**

1. `iwl_mld_get_basic_rates_and_band()` is called, which sets `band`
   based on `link_conf->chanreq.oper.chan->band`
2. For NAN interfaces, `link_conf->chanreq.oper.chan` may be NULL,
   meaning `band` is never properly set
3. Looking at the function, `band` is declared as `u8 band` with no
   initializer — so it could be any value
4. The code then does `sband = mld->hw->wiphy->bands[band]` — if `band`
   is out of range (>= `NUM_NL80211_BANDS`), this is an **out-of-bounds
   array access**
5. If `sband` happens to be NULL or garbage, subsequent access to
   `sband->bitrates[i].hw_value` would be a **NULL pointer dereference
   or memory corruption**

### Bug Classification

This is a **potential out-of-bounds access / NULL pointer dereference**
bug. The `bands[]` array is indexed by `band` which could be
uninitialized/invalid when NAN interfaces don't have channel
information. This could lead to:
- Kernel crash/oops
- Memory corruption

### Scope and Risk Assessment

- **Files changed:** 1 file
- **Lines added:** 5 (including blank line)
- **Lines removed:** 0
- **Subsystem:** iwlwifi wireless driver (Intel WiFi)
- **Risk:** Very low — the check is purely additive, validates bounds
  before array access, and returns a safe default value
- **The WARN_ON** provides debugging info if this path is hit
  unexpectedly for non-NAN interfaces

### Key Concern: Code Maturity

The file is `drivers/net/wireless/intel/iwlwifi/mld/tx.c`. The "mld"
directory is relatively new in iwlwifi — it was introduced as part of
the iwlwifi restructuring. Let me check when this code was introduced.

Looking at the path `drivers/net/wireless/intel/iwlwifi/mld/`, this is
the newer MLD (Multi-Link Device) code path for iwlwifi. This code is
quite new and may not exist in older stable trees. The commit is on top
of Linux 6.19, so it would only be relevant for very recent stable trees
(6.12.y at earliest, likely only 6.13.y+).

### Dependency Check

The fix is self-contained. It adds a bounds check before an existing
array access. It doesn't depend on other patches. However, the entire
`mld/` directory may not exist in older stable trees, limiting which
stable versions this applies to.

### User Impact

- **Who is affected:** Users of Intel WiFi hardware using NAN (Neighbor
  Awareness Networking) functionality
- **Severity:** Potential kernel crash (out-of-bounds array access) —
  moderate to high
- **Trigger:** Transmitting frames over a NAN interface without channel
  information

### Decision

The fix:
- Is small and surgical (5 lines)
- Fixes a real bug (out-of-bounds array access that could cause a crash)
- Is obviously correct (bounds check before array index)
- Has no risk of regression (adds a safety check with safe fallback)
- Meets stable kernel criteria

The only concern is whether the `mld/` code exists in the target stable
trees, but that's a backporting logistics issue, not a reason to reject.
If the code exists in stable, this fix should be there too.

**YES**

 drivers/net/wireless/intel/iwlwifi/mld/tx.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mld/tx.c b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
index 3b4b575aadaa5..e3fb4fc4f452e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
@@ -345,6 +345,11 @@ u8 iwl_mld_get_lowest_rate(struct iwl_mld *mld,
 
 	iwl_mld_get_basic_rates_and_band(mld, vif, info, &basic_rates, &band);
 
+	if (band >= NUM_NL80211_BANDS) {
+		WARN_ON(vif->type != NL80211_IFTYPE_NAN);
+		return IWL_FIRST_OFDM_RATE;
+	}
+
 	sband = mld->hw->wiphy->bands[band];
 	for_each_set_bit(i, &basic_rates, BITS_PER_LONG) {
 		u16 hw = sband->bitrates[i].hw_value;
-- 
2.51.0