Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2026-04-22 at 21:57 +0200, Johannes Berg wrote:
> On Wed, 2026-04-22 at 12:54 -0700, Brian Norris wrote:
> > > 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.
> > 
> 
> There are some (response) buffers where the size is checked before
> copying, but I didn't trace this back further than the SKB coming from
> pcie/sdio/usb, but I don't see any check of the firmware-advertised size
> vs. the actual skb->len.
> 

In PCIe for example it looks like there are multiple length fields, and
various mwifiex_map_pci_memory() calls with different sizes

 - MWIFIEX_UPLD_SIZE (2312)
 - MWIFIEX_RX_DATA_BUF_SIZE (4k)
 - MAX_EVENT_SIZE (2k)

If we assume strict iommu we'll get protection there (even if bounce-
buffered due to the weird sizes).

I don't see however any cross-check of the cmd_resp->size vs. the actual
size. If we had _that_ then we could rely on the cmd_resp->size later I
guess...

This all seems way too complicated anyway - should probably only ever
have whole pages allocated, for example.

johannes