linux-kernel - Re: [PATCH 05/32] brcmfmac: Use mem_to_flex_dup() with struct brcmf_fweh_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <202205162056.F8D1BF3E@keescook>
Date:   Mon, 16 May 2022 20:57:42 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Arend van Spriel <arend.vanspriel@...adcom.com>
Cc:     "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/32] brcmfmac: Use mem_to_flex_dup() with struct
 brcmf_fweh_queue_item

On Mon, May 16, 2022 at 02:49:21PM +0200, Arend van Spriel wrote:
> On 5/4/2022 3:44 AM, Kees Cook wrote:
> > As part of the work to perform bounds checking on all memcpy() uses,
> > replace the open-coded a deserialization of bytes out of memory into a
> > trailing flexible array by using a flex_array.h helper to perform the
> > allocation, bounds checking, and copying.
> > 
> Reviewed-by: Arend van Spriel <aspriel@...il.com>

Thanks!

> > [...]
> > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
> > index bc3f4e4edcdf..bea798ca6466 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
> > @@ -32,8 +32,8 @@ struct brcmf_fweh_queue_item {
> >   	u8 ifidx;
> >   	u8 ifaddr[ETH_ALEN];
> >   	struct brcmf_event_msg_be emsg;
> > -	u32 datalen;
> > -	u8 data[];
> > +	DECLARE_FLEX_ARRAY_ELEMENTS_COUNT(u32, datalen);
> > +	DECLARE_FLEX_ARRAY_ELEMENTS(u8, data);
> >   };
> > [...]
> > @@ -414,8 +414,7 @@ void brcmf_fweh_process_event(struct brcmf_pub *drvr,
> >   	    datalen + sizeof(*event_packet) > packet_len)
> >   		return;
> > -	event = kzalloc(sizeof(*event) + datalen, gfp);
> > -	if (!event)
> > +	if (mem_to_flex_dup(&event, data, datalen, gfp))
> >   		return;
> >   	event->code = code;
> > @@ -423,8 +422,6 @@ void brcmf_fweh_process_event(struct brcmf_pub *drvr,
> >   	/* use memcpy to get aligned event message */
> >   	memcpy(&event->emsg, &event_packet->msg, sizeof(event->emsg));
> > -	memcpy(event->data, data, datalen);
> > -	event->datalen = datalen;
> 
> So does mem_to_flex_dup() store event->datalen?
> 
> Don't have the entire thread so missing bits and pieces, but at least this
> raises questions for me.

Yes, that's part of the internal workings here -- the flex array counter
is declared and will be set as part of the copy.

-- 
Kees Cook