From: Johannes Berg johannes.berg@intel.com
[ Upstream commit 8af596e8ae44c3bcf36d1aea09fc9a6f17c555e5 ]
In disconnect paths paths, local frame buffers are used to build deauthentication frames to send them over the air and as notifications to userspace. Some internal error paths (that, given no other bugs, cannot happen) don't always initialize the buffers before sending them to userspace, so in the presence of other bugs they can leak stack content. Initialize the buffers to avoid the possibility of this happening.
Suggested-by: Zhongqiu Han quic_zhonhan@quicinc.com Link: https://patch.msgid.link/20250701072213.13004-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis, here is my conclusion:
**YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **Security Impact**: This is a security fix that prevents potential leakage of stack content to userspace. The commit message explicitly states that "in the presence of other bugs they can leak stack content."
2. **Bug Fix Nature**: The commit fixes a clear bug where frame buffers can be used uninitialized in error paths. Looking at the code: - In `ieee80211_set_disassoc()`, there are three early return paths (lines 3936, 3939, 3942) that can exit without initializing `frame_buf` - If these error paths are taken, the caller's `frame_buf` remains uninitialized - The caller (e.g., `__ieee80211_disconnect()`) then passes this uninitialized buffer to `ieee80211_report_disconnect()`, which ultimately sends it to userspace via `cfg80211_tx_mlme_mgmt()`
3. **Minimal and Contained Fix**: The fix is extremely simple - just adding a `memset(frame_buf, 0, IEEE80211_DEAUTH_FRAME_LEN)` at the beginning of the function. This is a safe, minimal change with no architectural impact.
4. **Low Risk**: The change has virtually no risk of regression as it only initializes memory that should have been initialized anyway. It doesn't change any logic or behavior.
5. **Similar to Historical Backports**: This fix is similar in nature to the first historical commit example ("wifi: cfg80211: avoid leaking stack data into trace") which was marked for backporting. Both fix stack data leaks with simple initialization.
6. **Defensive Programming**: Even though the error paths are marked with WARN_ON (indicating they "cannot happen" under normal circumstances), the commit message acknowledges that "in the presence of other bugs" these paths could be triggered. This defensive approach is exactly what stable kernels need.
The fix meets all stable kernel criteria: it fixes an important security issue (information leak), is minimal and contained, has low regression risk, and doesn't introduce new features or architectural changes.
net/mac80211/mlme.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 53d5ffad87be8..36fc496a906a1 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -3933,6 +3933,9 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
lockdep_assert_wiphy(local->hw.wiphy);
+ if (frame_buf) + memset(frame_buf, 0, IEEE80211_DEAUTH_FRAME_LEN); + if (WARN_ON(!ap_sta)) return;