linux-kernel - Re: [PATCH v2] rtl8723bs: fix memory leak error

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]

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