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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220105143740.GE7674@kadam>
Date:   Wed, 5 Jan 2022 17:37:40 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     "F.A.Sulaiman" <asha.16@...ac.mrt.ac.lk>
Cc:     gregkh@...uxfoundation.org, fabioaiuto83@...il.com,
        marcocesati@...il.com, hdegoede@...hat.com,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rtl8723bs: fix memory leak error

On Wed, Jan 05, 2022 at 06:04:47PM +0530, F.A.Sulaiman wrote:
> Smatch reported memory leak bug in rtl8723b_FirmwareDownload function.
> The problem is pFirmware memory is not released in 'release_fw1'.
> Instead of redirecting to 'release_fw1', we can turn it into 'exit'
> and free the memory.
> 
> Signed-off-by: F.A. SULAIMAN <asha.16@...ac.mrt.ac.lk>
> ---

Please say what changed in between v1 and v2 here, below the --- cut
off line.

>  drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
> index f1fc077ed29c..5f09b3ef9459 100644
> --- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
> +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
> @@ -361,7 +361,7 @@ s32 rtl8723b_FirmwareDownload(struct adapter *padapter, bool  bUsedWoWLANFw)
>  		netdev_emerg(padapter->pnetdev,
>  			     "Firmware size:%u exceed %u\n",
>  			     pFirmware->fw_length, FW_8723B_SIZE);
> -		goto release_fw1;
> +		goto exit;

I replied to the v1 version of this patch to say that this path needs
to call release_firmware().  That's true, although my proposed solution
introduced a double free.  The better way in this case is to call
release_firmware() before the goto.  The pattern is "unwind temporary
things and partial iterations before the goto".

The other stuff that I said in my email is still correct.  Just re-write
the error handling completely.  No point in me reviewing the function
every couple weeks when we could easily just fix it instead.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ