linux-kernel - RE: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <PA4PR04MB96387683672C8C39CD982711D18CA@PA4PR04MB9638.eurprd04.prod.outlook.com>
Date: Thu, 14 Dec 2023 23:05:07 +0000
From: David Lin <yu-hao.lin@....com>
To: Brian Norris <briannorris@...omium.org>
CC: Francesco Dolcini <francesco@...cini.it>, "linux-wireless@...r.kernel.org"
	<linux-wireless@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kvalo@...nel.org" <kvalo@...nel.org>, Pete
 Hsieh <tsung-hsien.hsieh@....com>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP

> From: Brian Norris <briannorris@...omium.org>
> Sent: Friday, December 15, 2023 2:52 AM
> To: David Lin <yu-hao.lin@....com>
> Cc: Francesco Dolcini <francesco@...cini.it>; linux-wireless@...r.kernel.org;
> linux-kernel@...r.kernel.org; kvalo@...nel.org; Pete Hsieh
> <tsung-hsien.hsieh@....com>; stable@...r.kernel.org
> 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@....com> wrote:
> > > From: Francesco Dolcini <francesco@...cini.it>
> > >
> > > On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote:
> > > > > From: Brian Norris <briannorris@...omium.org> 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.