[PATCH AUTOSEL 6.15 115/118] wifi: ath12k: fix link valid field initialization in the monitor Rx

[Sasha Levin]

From: Hari Chandrakanthan <quic_haric at quicinc.com>

[ Upstream commit 2826139f9295821fe2b049318a1cc057ec003131 ]

Currently, the link_valid field is not initialized in the monitor Rx path.
This can result in random values for the link_valid and link_id leads to
undefined behaviour in mac80211. Therefore, initialize the link_valid
field in the monitor Rx path.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: Hari Chandrakanthan <quic_haric at quicinc.com>
Tested-by: Nicolas Escande <nico.escande at gmail.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan at oss.qualcomm.com>
Signed-off-by: Karthikeyan Periyasamy <quic_periyasa at quicinc.com>
Link: https://patch.msgid.link/20250324062518.2752822-2-quic_periyasa@quicinc.com
Signed-off-by: Jeff Johnson <jeff.johnson at oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---

Based on my analysis of the commit and the code context, here is my
assessment: **YES** This commit should be backported to stable kernel
trees. Here's my extensive analysis: ## Technical Analysis **Code Change
Impact:** The commit adds a single line `status->link_valid = 0;` at the
beginning of the `ath12k_dp_mon_rx_deliver_msdu()` function in the
monitor Rx path. This initializes the `link_valid` field in the
`ieee80211_rx_status` structure before any subsequent processing. **Root
Cause and Problem:** 1. **Uninitialized Memory Issue**: The
`ieee80211_rx_status` structure contains the `link_valid` field (1 bit)
and `link_id` field (4 bits) that were not being initialized in the
monitor Rx path. 2. **Undefined Behavior**: Without initialization,
these fields contain random stack memory values, which can cause
unpredictable behavior in mac80211 when it processes received frames. 3.
**MLO Context**: The `link_valid` and `link_id` fields are specifically
used for Multi-Link Operation (MLO) in WiFi 7, where mac80211 needs to
know which link a frame was received on. ## Why This Should Be
Backported **1. Bug Fix Nature:** - This is clearly a bug fix that
addresses undefined behavior caused by uninitialized fields - The commit
message explicitly states this fixes "undefined behaviour in mac80211" -
Similar to reference commit #2 (which was backported) that fixed
uninitialized variables **2. User Impact:** - Uninitialized fields can
cause mac80211 to make incorrect decisions about packet processing - May
lead to packet drops, incorrect link handling, or other unpredictable
wireless behavior - Monitor mode is commonly used by network analysis
tools, making this user-facing **3. Risk Assessment:** - **Very Low
Risk**: The change is minimal (single line initialization) - **No Side
Effects**: Setting `link_valid = 0` is the correct default for monitor
mode - **Safe Change**: Only affects the monitor Rx path, doesn't change
core functionality **4. Code Pattern Consistency:** Looking at the
regular Rx path in `dp_rx.c`, I can see the same pattern: ```c if
(pubsta && pubsta->valid_links) { status->link_valid = 1;
status->link_id = peer->link_id; } ``` The monitor path was missing the
corresponding initialization, creating an inconsistency where: - Regular
Rx path: Properly sets `link_valid = 1` when appropriate - Monitor Rx
path: Left `link_valid` uninitialized (now fixed to `link_valid = 0`)
**5. Containment:** - Change is confined to a single function in the
monitor path - No architectural changes or new feature additions -
Follows established kernel practices for field initialization **6.
Stable Tree Criteria Match:** - ✅ Important bug fix (undefined behavior)
- ✅ Minimal risk of regression - ✅ Small, contained change - ✅ No new
features - ✅ Affects user-facing functionality (monitor mode) **7.
Reference Precedent:** This follows the same pattern as the backported
commit #2 which fixed uninitialized variables and commit #3 which fixed
incorrect field usage, both of which were deemed suitable for
backporting. The commit properly addresses a real bug that could affect
users of monitor mode with ath12k WiFi 7 devices, with virtually no risk
of introducing regressions.

 drivers/net/wireless/ath/ath12k/dp_mon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath12k/dp_mon.c b/drivers/net/wireless/ath/ath12k/dp_mon.c
index d22800e894850..b1350e60e2131 100644
--- a/drivers/net/wireless/ath/ath12k/dp_mon.c
+++ b/drivers/net/wireless/ath/ath12k/dp_mon.c
@@ -1970,6 +1970,8 @@ static void ath12k_dp_mon_rx_deliver_msdu(struct ath12k *ar, struct napi_struct
 	bool is_mcbc = rxcb->is_mcbc;
 	bool is_eapol_tkip = rxcb->is_eapol;
 
+	status->link_valid = 0;
+
 	if ((status->encoding == RX_ENC_HE) && !(status->flag & RX_FLAG_RADIOTAP_HE) &&
 	    !(status->flag & RX_FLAG_SKIP_MONITOR)) {
 		he = skb_push(msdu, sizeof(known));
-- 
2.39.5