[PATCH AUTOSEL 6.19-6.12] wifi: cfg80211: allow only one NAN interface, also in multi radio

[Sasha Levin <sashal@kernel.org>]

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

[ Upstream commit e69fda4d07701373354e52b0321bd40311d743d0 ]

According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can
have one NAN management interface. This applies also to multi radio
devices.
The current code allows a driver to support more than one NAN interface,
if those are not in the same radio.

Fix it.

Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### Key Finding: Limited Stable Tree Applicability

The multi-radio interface combination checking (`combined_radio`
parameter) was introduced in commit `bd9813d13be43` which was merged in
the v6.13 cycle. This means:
- The bug being fixed **only exists in kernels 6.13+**
- Older stable trees (6.12.y, 6.6.y, 6.1.y, 5.15.y, etc.) don't have the
  multi-radio combination checking code, so they don't have this bug
- Only 6.13.y and later stable trees would need this fix

### Assessment

**What the fix does**: Removes an incorrect exemption that allowed
multi-radio Wi-Fi devices to declare support for multiple NAN
interfaces, violating the Wi-Fi Aware specification.

**Severity**: Low-to-medium. This is a validation/spec-compliance fix.
The practical impact depends on whether any driver actually tries to
register multiple NAN interfaces across radios. If they do, NAN behavior
could be undefined per spec. The fix prevents such invalid
configurations from being accepted.

**Risk**: Very low. The change is tiny (removes one condition), is in a
validation path, and can only make the kernel *stricter* (reject invalid
configurations that were previously accepted). It cannot introduce new
crashes or regressions.

**Meets stable criteria**:
- Small and contained: Yes (removes ~4 lines)
- Fixes a real bug: Yes (incorrect validation allowing spec-violating
  configurations)
- Obviously correct: Yes (reviewed by the wireless maintainer)
- No new features: Correct, it tightens existing validation

**Concerns**:
- Limited applicability (only 6.13+ stable trees)
- Low severity - this is spec compliance rather than a crash/corruption
  fix
- The practical impact is limited since it only matters if a driver
  declares >1 NAN interface across radios

This is a legitimate, low-risk bug fix that enforces correct Wi-Fi
specification compliance. While the severity is not high (no
crash/corruption), it's a clean, reviewed fix from the subsystem
maintainer that corrects incorrect behavior. It's applicable to recent
stable trees (6.13+) and carries essentially zero regression risk.

**YES**

 net/wireless/core.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 9a420d627d3ce..2028bf5686f2b 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -661,12 +661,8 @@ int wiphy_verify_iface_combinations(struct wiphy *wiphy,
 				    c->limits[j].max > 1))
 				return -EINVAL;
 
-			/* Only a single NAN can be allowed, avoid this
-			 * check for multi-radio global combination, since it
-			 * hold the capabilities of all radio combinations.
-			 */
-			if (!combined_radio &&
-			    WARN_ON(types & BIT(NL80211_IFTYPE_NAN) &&
+			/* Only a single NAN can be allowed */
+			if (WARN_ON(types & BIT(NL80211_IFTYPE_NAN) &&
 				    c->limits[j].max > 1))
 				return -EINVAL;
 
-- 
2.51.0