RE: [PATCH 0/1] wifi: iwlwifi: mld: fix TSO segmentation explosion causing UAF

["Korenblit, Miriam Rachel" <miriam.rachel.korenblit@intel.com>]

> -----Original Message-----
> From: Cole Leavitt <cole@unwrap.rs>
> Sent: Wednesday, February 18, 2026 4:47 PM
> To: greearb@candelatech.com
> Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; Korenblit, Miriam
> Rachel <miriam.rachel.korenblit@intel.com>; Cole Leavitt <cole@unwrap.rs>
> Subject: [PATCH 0/1] wifi: iwlwifi: mld: fix TSO segmentation explosion causing
> UAF
> 
> Ben,
> 
> I've been digging into the use-after-free crash you reported on your
> BE200 running the MLD driver (tcp_shifted_skb refcount underflow, followed by
> NULL deref in tcp_rack_detect_loss). I think I found the root cause -- it's a
> missing guard in the MLD TSO segmentation path that lets num_subframes=0
> reach skb_gso_segment(), producing the 32k+ segment explosion you're seeing.
> 
> Here's the full chain:
> 
> 1) mld/tlc.c:790 -- when firmware's TLC notification disables AMSDU for
>    a TID (bit not set in amsdu_enabled), the MLD driver sets:
> 
>      link_sta->agg.max_tid_amsdu_len[i] = 1;
> 
>    This sentinel value 1 means "AMSDU disabled on this TID".
> 
> 2) mld/tx.c:836-837 -- the TSO path checks:
> 
>      max_tid_amsdu_len = sta->cur->max_tid_amsdu_len[tid];
>      if (!max_tid_amsdu_len)   // <-- only catches zero, not 1
>          return iwl_tx_tso_segment(skb, 1, ...);
> 
>    Value 1 passes this check.
> 
> 3) mld/tx.c:847 -- the division produces zero:
> 
>      num_subframes = (1 + 2) / (1534 + 2) = 0
> 
>    Any max_tid_amsdu_len below ~1534 (one subframe) produces 0 here.
> 
> 4) iwl-utils.c:27 -- gso_size is set to zero:
> 
>      skb_shinfo(skb)->gso_size = num_subframes * mss = 0 * 1460 = 0
> 
> 5) iwl-utils.c:30 -- skb_gso_segment() with gso_size=0 creates 32001+
>    tiny segments, which is the error you're seeing:
> 
>      "skbuff: ERROR: Found more than 32000 packets in skb_segment"
>      "iwl-mvm-tx-tso-segment, list gso-segment list is huge: 32001"
> 
> 6) mld/tx.c:912-936 -- the loop queues ~1024 of those segments to the
>    TX ring before it fills up, then purges the rest. This creates a
>    massive burst of tiny frames that stress the BA completion path.
> 
> The MVM driver is immune because it checks mvmsta->amsdu_enabled (a
> separate bitmap) at tx.c:912 and tx.c:936 BEFORE ever reaching the
> num_subframes calculation. MLD has no equivalent -- it relies solely on
> max_tid_amsdu_len, and the sentinel value 1 slips through.
> 
> This explains all your observations:
> - 6.18 regression: BE200 moved from MVM (has guard) to MLD (no guard)
> - AP-specific: the problem AP causes firmware to disable AMSDU for the
>   active TID (other APs enable it, so max_tid_amsdu_len gets a proper
>   value from iwl_mld_get_amsdu_size_of_tid())
> - 28min gap between TSO explosion and UAF: the ~1024 micro-frame burst
>   creates massive alloc/free churn in the skb slab, which can corrupt
>   TCP retransmit queue entries allocated from the same cache
> - No firmware error: firmware is fine, the bug is purely in MLD's TSO
>   parameter calculation
> 
> The fix (in patch 1/1) adds a guard after the num_subframes calculation -- if it's
> zero, fall back to single-subframe TSO (num_subframes=1), which correctly sets
> gso_size=mss. This matches what MVM effectively does via its amsdu_enabled
> checks.
> 
> Could you test this against the problem AP? Two things that would help confirm
> the theory:
> 
> 1) Before applying the fix, add this debug print to see the actual
>    max_tid_amsdu_len value with the problem AP:
> 
>      // In iwl_mld_tx_tso_segment(), after line 847
>      if (!num_subframes)
>          pr_warn_once("iwlmld: num_subframes=0, max_tid_amsdu_len=%u "
>                       "subf_len=%u mss=%u\n",
>                       max_tid_amsdu_len, subf_len, mss);
> 
> 2) After applying the fix, run against the problem AP for 1+ day and
>    check if both the TSO explosion AND the UAF are gone.
> 
> I also noticed a few secondary defense-in-depth regressions in MLD's TX
> completion path vs MVM:
> 
> - MLD's iwl_mld_tx_reclaim_txq() has no per-TID reclaim tracking
>   (MVM has tid_data->next_reclaimed and validates tid_data->txq_id)
> - The transport-level reclaim_lock prevents direct double-free, but
>   MLD is missing MVM's extra safety checks
> 
> These are probably not directly causing your crash, but worth noting.
> 
> Cole Leavitt (1):
>   wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is
>     disabled
> 
>  drivers/net/wireless/intel/iwlwifi/mld/tx.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> --
> 2.52.0

Thank you for the clear analysis!

Miri