From: Shmulik Cohen <anuk909@gmail.com>
To: stas.yakovlev@gmail.com
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, Shmulik Cohen <anuk909@gmail.com>
Subject: [PATCH 3/3] wifi: ipw2x00: bound management frame length to the receive buffer
Date: Wed, 12 Aug 2026 22:04:12 +0300 [thread overview]
Message-ID: <20260812190412.18333-4-anuk909@gmail.com> (raw)
In-Reply-To: <20260812190412.18333-1-anuk909@gmail.com>
Both management receive paths establish a lower bound on the frame
length and no upper bound, even though the length originates from the
device.
ipw2100_corruption_check() returns 0 without inspecting frame_size for
management frames, and __ipw2100_rx_process() only rejects a frame
smaller than the three-address header, so any reported size up to the
u32 limit reaches libipw_rx_mgt() against a receive allocation of
IPW_RX_NIC_BUFFER_LENGTH bytes. Check frame_size itself rather than
stats.len, which is a u16: a size of 65566 truncates to 30 on
assignment and would pass a check made afterwards.
ipw_rx() likewise only rejects a frame shorter than the header length.
Bound it against the DMA mapped receive buffer. The size passed to
alloc_skb() is rounded up by the allocator, so skb_tailroom() can
exceed IPW_RX_BUF_SIZE and is not a usable bound here; the existing
uses of that idiom in the data paths are too permissive for the same
reason.
libipw then hands the remainder to libipw_parse_info_param(), which
walks information elements for as long as the length allows, so an
over-long reported length reads past the receive buffer without any
wraparound being involved.
The length is device-reported, so per
Documentation/process/threat-model.rst this is a robustness fix rather
than a vulnerability.
Found by an AI-assisted review of length arithmetic in management frame
parsers. Compile-tested only for these two hunks; I do not have the
hardware, so they are not tested on a real device.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shmulik Cohen <anuk909@gmail.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 4 +++-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 9 +++++++++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 2b8a23865bfb..43b4e432956b 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -2712,7 +2712,9 @@ static void __ipw2100_rx_process(struct ipw2100_priv *priv)
break;
}
#endif
- if (stats.len < sizeof(struct libipw_hdr_3addr))
+ if (sq->drv[i].frame_size <
+ sizeof(struct libipw_hdr_3addr) ||
+ sq->drv[i].frame_size > IPW_RX_NIC_BUFFER_LENGTH)
break;
switch (WLAN_FC_GET_TYPE(le16_to_cpu(u->rx_data.header.frame_ctl))) {
case IEEE80211_FTYPE_MGMT:
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 4bc9bb406e8e..8249d493ee22 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -8322,6 +8322,15 @@ static void ipw_rx(struct ipw_priv *priv)
break;
}
+ if (unlikely(le16_to_cpu(pkt->u.frame.length) >
+ IPW_RX_BUF_SIZE -
+ IPW_RX_FRAME_SIZE)) {
+ IPW_DEBUG_DROP("Received oversized packet. Dropping.\n");
+ priv->net_dev->stats.rx_errors++;
+ priv->wstats.discard.misc++;
+ break;
+ }
+
switch (WLAN_FC_GET_TYPE
(le16_to_cpu(header->frame_ctl))) {
--
2.50.1 (Apple Git-155)
prev parent reply other threads:[~2026-08-12 19:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 19:04 [PATCH 0/3] wifi: ipw2x00: fix management frame length handling Shmulik Cohen
2026-08-12 19:04 ` [PATCH 1/3] wifi: libipw: reject too-short beacon and probe responses Shmulik Cohen
2026-08-12 19:04 ` [PATCH 2/3] wifi: libipw: reject too-short association responses Shmulik Cohen
2026-08-12 19:04 ` Shmulik Cohen [this message]
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=20260812190412.18333-4-anuk909@gmail.com \
--to=anuk909@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=stas.yakovlev@gmail.com \
/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