All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "F.A.Sulaiman" <asha.16@itfac.mrt.ac.lk>
Cc: gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: rtl8723bs: fix memory leak error
Date: Tue, 31 Aug 2021 11:47:35 +0300	[thread overview]
Message-ID: <20210831084735.GL12231@kadam> (raw)
In-Reply-To: <20210830193355.11338-1-asha.16@itfac.mrt.ac.lk>

On Tue, Aug 31, 2021 at 01:03:55AM +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@itfac.mrt.ac.lk>
> ---
>  drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
> index de8caa6cd418..b59c2aa3a9d8 100644
> --- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
> +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
> @@ -436,7 +436,7 @@ s32 rtl8723b_FirmwareDownload(struct adapter *padapter, bool  bUsedWoWLANFw)
>  	if (pFirmware->fw_length > FW_8723B_SIZE) {
>  		rtStatus = _FAIL;
>  		DBG_871X_LEVEL(_drv_emerg_, "Firmware size:%u exceed %u\n", pFirmware->fw_length, FW_8723B_SIZE);
> -		goto release_fw1;
> +		goto exit;
>  	}

The current tree doesn't have DBG_871X_LEVEL() so you must be working
against something old.  You need to work against linux-next or staging
next.

Your patch fixes a bug, but it would be better to just re-write the
error handling for this function.  There is another bug that a bunch
of error paths don't call release_firmware(fw).  Use the "Free the Last
Thing" method.

	pFirmware = kzalloc(sizeof(struct rt_firmware), GFP_KERNEL);
	if (!pFirmware)
		return _FAIL;

The last thing we allocated is "pFirmware" so free that if we have an
error.

	pBTFirmware = kzalloc(sizeof(struct rt_firmware), GFP_KERNEL);
	if (!pBTFirmware) {
		rtStatus = _FAIL;
		goto free_firmware;
	}

Now the last thing is pBTFirmware.

	rtStatus = request_firmware(&fw, fwfilepath, device);
	if (rtStatus) {
		rtStatus = _FAIL;
		goto free_bt_firmware;
	}

Now the last thing is "fw".  But this is a bit tricky because we're
going to release it as soon as possible and not wait until the end of
the function.  There isn't a reason for this...  We can change that or
keep it as-is.  If we keep it as is, then the we'll just call
release_firmware(fw); before the goto free_bt_firmware;  The current
code leaks fw on a bunch of error paths.

	pFirmware->fw_buffer_sz = kmemdup(fw->data, fw->size, GFP_KERNEL);
	if (!pFirmware->fw_buffer_sz) {
		rtStatus = _FAIL;
		release_firmware(fw);
		goto free_bt_firmware;
	}

Or:

	pFirmware->fw_buffer_sz = kmemdup(fw->data, fw->size, GFP_KERNEL);
	if (!pFirmware->fw_buffer_sz) {
		rtStatus = _FAIL;
		goto release_fw;
	}

Now the last thing is pFirmware->fw_buffer_sz.  Etc.

Then at the end it's just:

free_fw_buffer:
        kfree(pFirmware->fw_buffer_sz);
release_fw:
	release_firmware(fw);
free_bt_firmware:
	kfree(pBTFirmware);
free_firmware:
        kfree(pFirmware);

        return rtStatus;
}

regards,
dan carpenter

  reply	other threads:[~2021-08-31  8:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 19:33 [PATCH] staging: rtl8723bs: fix memory leak error F.A.Sulaiman
2021-08-31  8:47 ` Dan Carpenter [this message]
2021-09-01 18:54   ` F.A. SULAIMAN
2022-01-05 12:34 ` [PATCH v2] " F.A.Sulaiman
2022-01-05 14:37   ` Dan Carpenter
2022-01-06 21:00   ` kernel test robot
2022-01-06 21:00     ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210831084735.GL12231@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=asha.16@itfac.mrt.ac.lk \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.