> From: Brian Norris <briannorris@xxxxxxxxxxxx> > Sent: Friday, December 15, 2023 2:52 AM > To: David Lin <yu-hao.lin@xxxxxxx> > Cc: Francesco Dolcini <francesco@xxxxxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; kvalo@xxxxxxxxxx; Pete Hsieh > <tsung-hsien.hsieh@xxxxxxx>; stable@xxxxxxxxxxxxxxx > Subject: Re: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On Thu, Dec 14, 2023 at 3:38 AM David Lin <yu-hao.lin@xxxxxxx> wrote: > > > From: Francesco Dolcini <francesco@xxxxxxxxxx> > > > > > > On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote: > > > > > From: Brian Norris <briannorris@xxxxxxxxxxxx> It probably > > > > > wouldn't hurt to significantly write much of this driver, but at > > > > > a minimum, we could probably use a few checks like this: > > > > > > > > > > cmd_size += sizeof(struct host_cmd_tlv_mac_addr); > > > > > if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) > > > > > return -1; > > > > > // Only touch tlv *after* the bounds check. > > > > > > > > > > That doesn't need to block this patch, of course. > > > > > > > > > > Brian > > > > > > > > > > > > > I will modify the code for next patch. > > > > > > I would suggest not modify this in this patch, we should fix all the > > > code that is subjected to this potential issue. > > > > > > I would personally do a follow-up patch just to add the check to > > > avoid overflowing the cmd buffer everywhere it is used. > > Right, there's tons of code that could potentially be affected, and this is > definitely a separate patch. (Your feature only adds on to the existing issue, > so these are separate logical changes.) > > > O.K. I will only change commit message. In fact, this TLV command is added > as the first one command. > > Well, it doesn't really matter than your TLV is "first" -- if there's an overflow, > there's an overflow. Maybe the 8 bytes you're adding here are the necessary > tipping point. I don't know without doing some kind of informal > mathematics/proof. > > Brian Understood. Thanks.
