Received-SPF: pass (google.com: domain of linux-wireless+bounces-814-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231208234127.2251-1-yu-hao.lin@nxp.com> <ZXpjjmD5Se7axJju@google.com>
 <PA4PR04MB96383A106724AC1CE683112BD18CA@PA4PR04MB9638.eurprd04.prod.outlook.com>
 <ZXqwP7NscRtE1uGL@francesco-nb.int.toradex.com> <PA4PR04MB96380AA7B60AFD73491FF53BD18CA@PA4PR04MB9638.eurprd04.prod.outlook.com>
In-Reply-To: <PA4PR04MB96380AA7B60AFD73491FF53BD18CA@PA4PR04MB9638.eurprd04.prod.outlook.com>
From: Brian Norris <briannorris@chromium.org>
Date: Thu, 14 Dec 2023 10:52:29 -0800
Message-ID: <CA+ASDXOHQUnruWqsN0yTbKzVD8+7hcafLFhhv6jq7cdUzTY5ZA@mail.gmail.com>
Subject: Re: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP
To: David Lin <yu-hao.lin@nxp.com>
Cc: Francesco Dolcini <francesco@dolcini.it>, 
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kvalo@kernel.org" <kvalo@kernel.org>, 
	Pete Hsieh <tsung-hsien.hsieh@nxp.com>, 
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 14, 2023 at 3:38=E2=80=AFAM David Lin <yu-hao.lin@nxp.com> wrot=
e:
> > From: Francesco Dolcini <francesco@dolcini.it>
> >
> > On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote:
> > > > From: Brian Norris <briannorris@chromium.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 t=
his:
> > > >
> > > >         cmd_size +=3D 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 co=
de 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 adde=
d 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