All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuchao Zhang <ndaugoing@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Yuchao Zhang <ndaugoing@gmail.com>
Subject: [PATCH 0/1] wifi: mac80211: drop oversized fragments to avoid extra_len overflow
Date: Fri, 18 Sep 2026 11:40:03 +0800	[thread overview]
Message-ID: <20260918034004.85078-1-ndaugoing@gmail.com> (raw)

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


             reply	other threads:[~2026-09-18  3:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  3:40 Yuchao Zhang [this message]
2026-09-18  3:40 ` [PATCH 1/1] wifi: mac80211: drop oversized fragments to avoid extra_len overflow Yuchao Zhang

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=20260918034004.85078-1-ndaugoing@gmail.com \
    --to=ndaugoing@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.