linux-kernel - Re: [PATCH] staging: rtl8712: fix a potential memory leak in r871xu_drv

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: <20220405112058.GG3293@kadam>
Date:   Tue, 5 Apr 2022 14:20:58 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     xkernel.wang@...mail.com
Cc:     gregkh@...uxfoundation.org, Larry.Finger@...inger.net,
        florian.c.schilhabel@...glemail.com, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8712: fix a potential memory leak in
 r871xu_drv_init()

On Tue, Apr 05, 2022 at 12:43:07PM +0800, xkernel.wang@...mail.com wrote:
> From: Xiaoke Wang <xkernel.wang@...mail.com>
> 
> In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory
> allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not
> properly released as there is no action will be performed by
> r8712_usb_dvobj_deinit().
> To properly release it, we should call r8712_free_io_queue() in
> r8712_usb_dvobj_deinit().
> 
> Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called
> by r871x_dev_unload() under condition `padapter->bup` and
> r8712_free_io_queue() is called by r8712_free_drv_sw().
> However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and
> calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for
> better understading the code.
> So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove
> r8712_free_io_queue() from r8712_free_drv_sw().
> 
> Signed-off-by: Xiaoke Wang <xkernel.wang@...mail.com>
> ---

Sounds reasonable.

Reviewed-by: Dan Carpenter <dan.carpenter@...cle.com>

regards,
dan carpenter