[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37b195b700394e95aa8329afc9f60431@AcuMS.aculab.com>
Date: Mon, 30 Sep 2019 13:18:32 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Denis Efremov' <efremov@...ux.com>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
Hans de Goede <hdegoede@...hat.com>,
Bastien Nocera <hadess@...ess.net>,
Larry Finger <Larry.Finger@...inger.net>,
Jes Sorensen <jes.sorensen@...il.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
From: Denis Efremov
> Sent: 30 September 2019 12:02
> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
> called with "src == NULL && len == 0". This is an undefined behavior.
I'm pretty certain it is well defined (to do nothing).
> Moreover this if pre-condition "pBufLen && (*pBufLen == 0) && !pBuf"
> is constantly false because it is a nested if in the else brach, i.e.,
> "if (cond) { ... } else { if (cond) {...} }". This patch alters the
> if condition to check "pBufLen && pBuf" pointers are not NULL.
>
...
> ---
> Not tested. I don't have the hardware. The fix is based on my guess.
>
> drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> index 6539bee9b5ba..0902dc3c1825 100644
> --- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> +++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> @@ -2320,7 +2320,7 @@ int phy_ConfigBBWithParaFile(
> }
> }
> } else {
> - if (pBufLen && (*pBufLen == 0) && !pBuf) {
> + if (pBufLen && pBuf) {
> memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
The existing code is clearly garbage.
It only ever does memcpy(tgt, NULL, 0).
Under the assumption that the code has been tested the copy clearly isn't needed at all
and can be deleted completely!
OTOH if the code hasn't been tested maybe the entire source file should be removed :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists