[PATCH AUTOSEL 6.18-5.10] wifi: mac80211: don't increment crypto_tx_tailroom_needed_cnt twice

[Sasha Levin <sashal@kernel.org>]

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

[ Upstream commit 3f3d8ff31496874a69b131866f62474eb24ed20a ]

In reconfig, in case the driver asks to disconnect during the reconfig,
all the keys of the interface are marked as tainted.
Then ieee80211_reenable_keys will loop over all the interface keys, and
for each one it will
a) increment crypto_tx_tailroom_needed_cnt
b) call ieee80211_key_enable_hw_accel, which in turn will detect that
this key is tainted, so it will mark it as "not in hardware", which is
paired with crypto_tx_tailroom_needed_cnt incrementation, so we get two
incrementations for each tainted key.
Then we get a warning in ieee80211_free_keys.

To fix it, don't increment the count in ieee80211_reenable_keys for
tainted keys

Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260118092821.4ca111fddcda.Id6e554f4b1c83760aa02d5a9e4e3080edb197aa2@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:

So KEY_FLAG_TAINTED was introduced in v4.20. The bug being fixed is
likely in all kernels from 4.20 onward. Let me verify the current state
after the patch would be applied.

The patch being analyzed changes:
```c
list_for_each_entry(key, &sdata->key_list, list) {
    increment_tailroom_need_count(sdata);  // OLD: unconditional
    ieee80211_key_enable_hw_accel(key);
}
```

to:
```c
list_for_each_entry(key, &sdata->key_list, list) {
    if (!(key->flags & KEY_FLAG_TAINTED))  // NEW: skip for tainted
        increment_tailroom_need_count(sdata);
    ieee80211_key_enable_hw_accel(key);
}
```

This is correct because:
- For non-tainted keys: increment once here, and if HW accel succeeds,
  it will be decremented in `ieee80211_key_enable_hw_accel()` (line
  187). Net result: proper accounting.
- For tainted keys: skip here, let `ieee80211_key_enable_hw_accel()`
  handle the increment (line 141) when clearing
  `KEY_FLAG_UPLOADED_TO_HARDWARE`. Net result: proper accounting.

## Analysis Summary

**1. COMMIT MESSAGE ANALYSIS:**
- Clear explanation of the problem: double increment of
  `crypto_tx_tailroom_needed_cnt` for tainted keys during reconfig
- The symptom is a warning in `ieee80211_free_keys`
- Reviewed-by from Johannes Berg (mac80211 maintainer) adds confidence

**2. CODE CHANGE ANALYSIS:**
- The bug: In `ieee80211_reenable_keys()`, for each key:
  1. `increment_tailroom_need_count(sdata)` is called unconditionally
  2. `ieee80211_key_enable_hw_accel(key)` is called

- For tainted keys (marked when driver requests disconnect during
  reconfig), `ieee80211_key_enable_hw_accel()` will:
  - Also call `increment_tailroom_need_count(sdata)` at line 141 if the
    key was uploaded to hardware
  - Clear the `KEY_FLAG_UPLOADED_TO_HARDWARE` flag

- Result: Two increments per tainted key instead of one

- The fix: Skip the first increment for tainted keys since they'll get
  their increment inside `ieee80211_key_enable_hw_accel()`

**3. CLASSIFICATION:**
- This is a clear BUG FIX for a reference counting error
- Not a feature addition
- Fixes a real warning that users would see in kernel logs

**4. SCOPE AND RISK ASSESSMENT:**
- Very small change: adds a simple conditional check (1 line changed)
- Localized to mac80211 key handling
- Low risk: the logic is straightforward and has been reviewed by the
  subsystem maintainer
- The worst-case if the fix is wrong would be the opposite accounting
  error

**5. USER IMPACT:**
- WiFi users doing rekeys or going through suspend/resume/HW restart
  with certain driver/firmware combinations could hit this
- The symptom is a kernel warning (WARN_ON_ONCE in
  `ieee80211_free_keys`)
- It causes incorrect tailroom accounting which could potentially lead
  to issues with software encryption

**6. STABILITY INDICATORS:**
- Reviewed-by: Johannes Berg (mac80211 maintainer)
- The code path and fix are straightforward

**7. DEPENDENCY CHECK:**
- KEY_FLAG_TAINTED exists since v4.20
- The function `ieee80211_reenable_keys()` exists in stable trees
- The code affected exists in all supported stable kernels
- No dependency on other commits - this is a standalone fix

The fix is small, surgical, reviewed by the subsystem maintainer, fixes
a real bug (warning + incorrect reference counting), and meets all
stable kernel criteria.

**YES**

 net/mac80211/key.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index d5da7ccea66e0..04c8809173d7f 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -987,7 +987,8 @@ void ieee80211_reenable_keys(struct ieee80211_sub_if_data *sdata)
 
 	if (ieee80211_sdata_running(sdata)) {
 		list_for_each_entry(key, &sdata->key_list, list) {
-			increment_tailroom_need_count(sdata);
+			if (!(key->flags & KEY_FLAG_TAINTED))
+				increment_tailroom_need_count(sdata);
 			ieee80211_key_enable_hw_accel(key);
 		}
 	}
-- 
2.51.0