public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Bommarito <michael.bommarito@gmail.com>
To: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Felix Fietkau <nbd@nbd.name>,
	Benjamin Berg <benjamin@sipsolutions.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michael Bommarito <michael.bommarito@gmail.com>
Subject: [PATCH] wifi: mac80211: check ieee80211_rx_data_set_link return in pubsta MLO path
Date: Tue, 21 Apr 2026 20:06:51 -0400	[thread overview]
Message-ID: <20260422000651.4184602-1-michael.bommarito@gmail.com> (raw)

__ieee80211_rx_handle_packet() resolves the link via
ieee80211_rx_data_set_link() on the pubsta->mlo path but ignores the
helper's return value.  Inside the helper,
  rx->link = rcu_dereference(rx->sdata->link[link_id]);
can leave rx->link NULL if link_id references a slot already cleared
by ieee80211_vif_set_links() during station-initiated ML
reconfiguration (see mlme.c's ieee80211_ml_reconfiguration(), which
invalidates sdata->link[] before the matching
ieee80211_sta_remove_link() loop walks the link-sta hash).  RX dispatch
still resolves a link_sta from the hash and then drops into
ieee80211_prepare_and_rx_handle(), which dereferences link->conf->addr.

Every other user site of ieee80211_rx_data_set_link() checks the return
and bails on failure; only this branch did not.  Mirror the safe
pattern.

Fixes: e66b7920aa5a ("wifi: mac80211: fix initialization of rx->link and rx->link_sta")
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
---

Notes for reviewers (not part of the commit):

Found by static audit of unchecked return values on
ieee80211_rx_data_set_link() call sites.  The non-pubsta
arm was already fixed upstream by commit 32d340ae6758 ("wifi:
mac80211: fix receiving MLO frames in the non-fast-path"); the
pubsta arm was missed, and this patch mirrors the same shape.

Runtime evidence:

 - Synthetic kernel-side A/B: on parent commit e66b7920aa5a..
   (pre-fix) forcing sdata->link[1] == NULL while sta->link[1]
   stays live causes ieee80211_rx_data_set_link() to return 0
   and ieee80211_prepare_and_rx_handle() to NULL-deref
   link->conf->addr; with the patch applied the guard drops
   the frame instead.

 - Source-level race window confirmed observationally: an
   instrumented pre-fix UML run with real hostapd + wpa_supplicant
   MLO and station-initiated SETUP_LINK_RECONFIG hits
   "sdata->link[1] == NULL while sta_valid_links still carries
   bit 1" on every reconfiguration attempt, inside
   ieee80211_setup_link_reconfig() between ieee80211_vif_set_links()
   and the per-link ieee80211_sta_remove_link() loop.

 - That same instrumented run does not itself crash, for two
   reasons independent of this bug: mac80211_hwsim feeds RX via
   ieee80211_rx_napi(hw, NULL, skb), so the pubsta arm at
   rx.c:5335 is unreachable from hwsim (frames take the
   already-fixed non-pubsta for_each_sta_info arm), and UML is
   single-CPU so RX softirq cannot interleave with the mlme
   reconfig sequence.  Real MLO-capable drivers (iwlwifi, mt76)
   do populate pubsta on their fast RX paths, and SMP hardware
   gives the race the micro-window it needs.

Benjamin Berg's 2026-02 RFC v2 "wifi: mac80211: refactor RX
link_id and station handling"
(20260223133818.9f5550ab445f.I...@changeid) touches the same
code and may supersede or subsume this patch; happy to fold /
rebase / drop.

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

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 11d6c56c9d7e..e0ab4852c0c6 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -5332,7 +5332,9 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
 				if (!link_sta)
 					goto out;
 
-				ieee80211_rx_data_set_link(&rx, link_sta->link_id);
+				if (!ieee80211_rx_data_set_link(&rx,
+								link_sta->link_id))
+					goto out;
 			}
 
 			if (ieee80211_prepare_and_rx_handle(&rx, skb, true))
-- 
2.53.0


             reply	other threads:[~2026-04-22  0:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22  0:06 Michael Bommarito [this message]
2026-04-22  6:27 ` [PATCH] wifi: mac80211: check ieee80211_rx_data_set_link return in pubsta MLO path Johannes Berg
2026-04-22  8:17   ` Benjamin Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260422000651.4184602-1-michael.bommarito@gmail.com \
    --to=michael.bommarito@gmail.com \
    --cc=benjamin@sipsolutions.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox