From: Brian Norris <briannorris@chromium.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Tristan Madani <tristmd@gmail.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Tristan Madani <tristan@talencesecurity.com>
Subject: Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
Date: Wed, 22 Apr 2026 12:54:16 -0700 [thread overview]
Message-ID: <aeknaNDFrmtuTQP1@google.com> (raw)
In-Reply-To: <2e20cb23d2d156963c2b687c4c51635e5eec2c7c.camel@sipsolutions.net>
On Wed, Apr 22, 2026 at 09:12:11PM +0200, Johannes Berg wrote:
> On Wed, 2026-04-22 at 11:26 -0700, Brian Norris wrote:
> >
> > > + u16 resp_size = le16_to_cpu(resp->size);
> > > + u16 count = le16_to_cpu(sta_list->sta_count);
> > > + u16 max_count;
> > >
> > > - for (i = 0; i < (le16_to_cpu(sta_list->sta_count)); i++) {
> > > + if (resp_size < sizeof(*resp) - sizeof(resp->params) + sizeof(*sta_list))
> > > + return -EINVAL;
> > > + max_count = (resp_size - sizeof(*resp) + sizeof(resp->params) -
> > > + sizeof(*sta_list)) / sizeof(*sta_info);
> >
> > The repeated arithmetic is a bit weird, but I'm not sure if it'd
> > actually be better to stash it in its own variable. Seems good enough I
> > suppose.
>
> I think it might be simpler if instead trying to limit:
>
> > > + count = min(count, max_count);
>
> it'd just check the needed length based on the given count, and reject
> anything above that?
That might be better.
> Also, the whole sizeof(*resp) - sizeof(resp->params) etc. shouldn't be
> there, that should just be
>
> offsetofend(resp, sta_list.tlv)
TIL. I don't recall seeing that macro before. Or at least, I didn't know
it well enough to recommend it.
> and then suddenly it becomes _way_ simpler:
>
> if (resp_size < offsetofend(resp, sta_list.tlv))
> return -EINVAL;
> if (resp_size < offsetofend(resp, sta_list.tlv) +
> sizeof(*sta_info) * le16_to_cpu(sta_.list->sta_count))
> return -EINVAL;
Looks good to me.
> But regardless, I question the sanity of checking the size against the
> size the firmware said the whole thing was going to be, rather than
> checking against the actual buffer size ...
Admittedly, I get lost in this driver sometimes...
...but I think you have a very good point. AFAICT, we never do anything
to check the size of adapter->curr_cmd->resp_skb. We generally assume
it's big enough to fit 'struct host_cmd_ds_command' (since we allocate
it ourselves). But we don't ever go back to check these
dynamically-sized fields don't overflow it.
Brian
next prev parent reply other threads:[~2026-04-22 19:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 13:49 [PATCH v3 0/6] wifi: mwifiex: firmware trust boundary hardening Tristan Madani
2026-04-21 13:49 ` [PATCH v3 1/6] wifi: mwifiex: fix OOB write from firmware queue_index in WMM status response Tristan Madani
2026-04-21 23:19 ` Brian Norris
2026-04-21 13:49 ` [PATCH v3 2/6] wifi: mwifiex: fix OOB write from firmware TID in ADDBA response handler Tristan Madani
2026-04-21 23:30 ` Brian Norris
2026-04-21 13:49 ` [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response Tristan Madani
2026-04-22 18:26 ` Brian Norris
2026-04-22 19:12 ` Johannes Berg
2026-04-22 19:54 ` Brian Norris [this message]
2026-04-22 19:57 ` Johannes Berg
2026-04-22 20:09 ` Johannes Berg
2026-04-22 19:06 ` Johannes Berg
2026-04-21 13:49 ` [PATCH v3 4/6] wifi: mwifiex: fix OOB read in scan response from mismatched TLV data sizes Tristan Madani
2026-04-22 18:28 ` Brian Norris
2026-04-21 13:49 ` [PATCH v3 5/6] wifi: mwifiex: fix OOB read from firmware intf_num in multichannel event Tristan Madani
2026-04-21 23:20 ` Brian Norris
2026-04-21 13:49 ` [PATCH v3 6/6] wifi: mwifiex: fix OOB read from inflated TLV length in IBSS peer event Tristan Madani
2026-04-21 23:20 ` Brian Norris
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=aeknaNDFrmtuTQP1@google.com \
--to=briannorris@chromium.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=tristan@talencesecurity.com \
--cc=tristmd@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 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.