* [PATCH 0/1] wifi: mac80211: drop oversized fragments to avoid extra_len overflow
@ 2026-09-18 3:40 Yuchao Zhang
2026-09-18 3:40 ` [PATCH 1/1] " Yuchao Zhang
0 siblings, 1 reply; 2+ messages in thread
From: Yuchao Zhang @ 2026-09-18 3:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, linux-kernel, Yuchao Zhang
Hi Johannes and mac80211 maintainers,
During static analysis of fragment reassembly in mac80211, we identified
a potential 16-bit integer overflow in ieee80211_rx_h_defragment() that
can be triggered by a sequence of oversized fragments, leading to an
undersized allocation in pskb_expand_head() followed by skb_over_panic()
in softirq context.
In commit 69f132236827 ("mac80211: shrink struct
ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned
int to u16. Since up to 16 fragments (frag numbers 0..15) can be received
in an IEEE 802.11 sequence, a sequence of large incoming fragments can
cause entry->extra_len to exceed 65535 bytes, wrapping around modulo
65536. When the final fragment arrives, pskb_expand_head() only allocates
tailroom for the wrapped-around extra_len, and the subsequent
skb_put_data() loop overflows the buffer, triggering skb_over_panic().
Because valid MSDUs in IEEE 802.11 are far below U16_MAX (standard MSDU
is <= 2304 bytes, and A-MSDU cannot be fragmented), we prevent this wrap
by dropping the frame and purging the queued fragments if accumulating
the incoming fragment length would exceed U16_MAX.
This approach keeps struct ieee80211_fragment_entry completely untouched,
preserving the structure memory reduction from the aforementioned commit.
Best regards,
Yuchao Zhang
Yuchao Zhang (1):
wifi: mac80211: drop oversized fragments to avoid extra_len overflow
net/mac80211/rx.c | 6 ++++++
1 file changed, 6 insertions(+)
--
2.53.0
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 1/1] wifi: mac80211: drop oversized fragments to avoid extra_len overflow
2026-09-18 3:40 [PATCH 0/1] wifi: mac80211: drop oversized fragments to avoid extra_len overflow Yuchao Zhang
@ 2026-09-18 3:40 ` Yuchao Zhang
0 siblings, 0 replies; 2+ messages in thread
From: Yuchao Zhang @ 2026-09-18 3:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, linux-kernel, Yuchao Zhang
In ieee80211_rx_h_defragment(), fragment payloads are accumulated into
entry->extra_len as subsequent fragments arrive:
entry->extra_len += rx->skb->len;
When the final fragment arrives, the head fragment is dequeued, and
pskb_expand_head() is called with entry->extra_len to ensure sufficient
tailroom for all queued fragments before copying:
if (skb_tailroom(rx->skb) < entry->extra_len) {
if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len,
GFP_ATOMIC))) {
...
}
}
while ((skb = __skb_dequeue(&entry->skb_list))) {
skb_put_data(rx->skb, skb->data, skb->len);
dev_kfree_skb(skb);
}
In commit 69f132236827 ("mac80211: shrink struct
ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned
int to u16 in order to reduce structure memory footprint.
However, an IEEE 802.11 frame sequence can contain up to 16 fragments
(frag numbers 0..15). If a sequence of large fragments arrives (e.g. from
a malicious peer or rogue AP), the sum of fragment lengths can exceed
65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes).
Because extra_len is a u16, this addition overflows and wraps around
modulo 65536 (e.g. 66000 wraps to 464).
Consequently, pskb_expand_head() allocates only the truncated amount of
tailroom (or is skipped entirely if the head fragment already has >= 464
bytes of tailroom). When skb_put_data() subsequently iterates through the
queued skb list, it appends the full payload into the undersized buffer,
causing skb_put() to trigger skb_over_panic() and crash the kernel in
softirq context.
A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454
bytes for A-MSDU, which is not fragmented), well below U16_MAX.
Fix this without increasing the size of struct ieee80211_fragment_entry by
checking whether adding the incoming fragment length would exceed U16_MAX.
If so, purge the queued fragments and drop the frame.
Fixes: 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry")
Signed-off-by: Yuchao Zhang <ndaugoing@gmail.com>
---
net/mac80211/rx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 5e26be8e27d8..e7292d5febf5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2499,6 +2499,12 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
}
skb_pull(rx->skb, ieee80211_hdrlen(fc));
+ if (unlikely((u32)entry->extra_len + rx->skb->len > U16_MAX)) {
+ I802_DEBUG_INC(rx->local->rx_handlers_drop_defrag);
+ __skb_queue_purge(&entry->skb_list);
+ return RX_DROP_U_DEFRAG_MISMATCH;
+ }
+
__skb_queue_tail(&entry->skb_list, rx->skb);
entry->last_frag = frag;
entry->extra_len += rx->skb->len;
--
2.53.0
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-18 3:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-18 3:40 [PATCH 0/1] wifi: mac80211: drop oversized fragments to avoid extra_len overflow Yuchao Zhang
2026-09-18 3:40 ` [PATCH 1/1] " Yuchao Zhang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®