From: Liao Yuanhong liaoyuanhong@vivo.com
[ Upstream commit a33b375ab5b3a9897a0ab76be8258d9f6b748628 ]
The variable ret is declared as a u32 type, but it is assigned a value of -EOPNOTSUPP. Since unsigned types cannot correctly represent negative values, the type of ret should be changed to int.
Signed-off-by: Liao Yuanhong liaoyuanhong@vivo.com Link: https://patch.msgid.link/20250825022911.139377-1-liaoyuanhong@vivo.com Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the following reasons:
## Analysis of the Code Change
The commit fixes a clear type mismatch bug in `net/mac80211/driver- ops.h:1419` where `ret` was incorrectly declared as `u32` while being assigned the negative error value `-EOPNOTSUPP` (-95):
```c // Before (incorrect): u32 ret = -EOPNOTSUPP; // Assigns -95 to unsigned, becomes 4294967201
// After (correct): int ret = -EOPNOTSUPP; // Properly represents -95 ```
## Why This Qualifies for Stable Backport
1. **Bug Fix**: This is a genuine bug that violates C type safety. Assigning negative values to unsigned types is incorrect and can lead to undefined behavior or compiler-specific interpretations.
2. **Long-standing Issue**: The bug has existed since kernel v4.20 (commit bc847970f43281cb, October 2018), affecting all stable kernels from 4.20 onwards. A 7-year-old bug deserves fixing in stable trees.
3. **Minimal and Contained**: The fix is a single-line type change from `u32` to `int`. It's about as minimal and low-risk as a kernel patch can be.
4. **No Functional Changes**: The fix doesn't introduce new features or change architecture - it simply corrects a type declaration to match its intended use.
5. **Correctness Over Impact**: While the practical impact was minimal due to implicit type conversion preserving the negative value when returned as `int`, this is still incorrect code that: - Violates type safety principles - Can trigger compiler warnings - Sets a bad example for similar code patterns - Could break with different compiler optimizations or architectures
6. **Affects Error Handling Path**: The bug is in error handling code (`-EOPNOTSUPP`), and correct error handling is critical for kernel stability. Even if the current behavior happens to work, relying on implicit conversions for error codes is dangerous.
7. **Simple Verification**: The fix is trivially verifiable - the function returns `int` and all error codes are negative, so `ret` should be `int`, not `u32`.
## Stable Tree Rules Compliance
The commit perfectly aligns with stable kernel rules: - ✅ Fixes a real bug (type mismatch) - ✅ Already merged in Linus' tree - ✅ Minimal size (1 line change) - ✅ No new features added - ✅ Low regression risk - ✅ Improves code correctness
The fact that this bug existed for 7 years without causing reported failures actually strengthens the case for backporting - it means the fix is extremely safe while still correcting incorrect code that could potentially cause issues with different compilers or architectures.
net/mac80211/driver-ops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h index 307587c8a0037..7964a7c5f0b2b 100644 --- a/net/mac80211/driver-ops.h +++ b/net/mac80211/driver-ops.h @@ -1389,7 +1389,7 @@ drv_get_ftm_responder_stats(struct ieee80211_local *local, struct ieee80211_sub_if_data *sdata, struct cfg80211_ftm_responder_stats *ftm_stats) { - u32 ret = -EOPNOTSUPP; + int ret = -EOPNOTSUPP;
might_sleep(); lockdep_assert_wiphy(local->hw.wiphy);