linux-kernel - Re: [PATCH] scsi: sni_53c710: Fix a resource leak in an error handling path

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:   Thu, 20 May 2021 17:06:41 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     jejb@...ux.ibm.com, martin.petersen@...cle.com,
        James.Bottomley@...elEye.com, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] scsi: sni_53c710: Fix a resource leak in an error
 handling path

On Thu, May 20, 2021 at 06:44:25AM +0200, Christophe JAILLET wrote:
> After a successful 'NCR_700_detect()' call, 'NCR_700_release()' must be
> called to release some DMA related resources, as already done in the
> remove function.
> 
> Fixes: c27d85f3f3c5 ("[SCSI] SNI RM 53c710 driver")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
> ---
>  drivers/scsi/sni_53c710.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/scsi/sni_53c710.c b/drivers/scsi/sni_53c710.c
> index 678651b9b4dd..f6d60d542207 100644
> --- a/drivers/scsi/sni_53c710.c
> +++ b/drivers/scsi/sni_53c710.c
> @@ -98,6 +98,7 @@ static int snirm710_probe(struct platform_device *dev)
>  
>   out_put_host:
>  	scsi_host_put(host);
> +	NCR_700_release(host);

shouldn't this done before the scsi_host_put() to avoid a use after free ?
lasi700.c has the same problem. And it looks like NCR_700_detect() will leak
dma memory, if scsi_host_alloc() failed.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]