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] [day] [month] [year] [list]
Message-ID: <dbb75c5a-5a61-4e46-a593-b6fb6d22703e@oracle.com>
Date: Tue, 20 Aug 2024 18:35:39 -0500
From: michael.christie@...cle.com
To: Ma Ke <make24@...as.ac.cn>, James.Bottomley@...senPartnership.com,
        martin.petersen@...cle.com, m.muzzammilashraf@...il.com,
        James.Bottomley@...e.de, kxie@...lsio.com, michaelc@...wisc.edu,
        akpm@...ux-foundation.org
Cc: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] scsi: iscsi: fix reference count leak in
 cxgbi_check_route()

On 8/19/24 4:24 AM, Ma Ke wrote:
> cxgbi_check_route() dont release the reference acquired by ip_dev_find()
> which introducing a reference count leak. We could remedy this by
> insuring the reference is released.ip_dev_find().
> 
> Cc: stable@...r.kernel.org
> Fixes: 9ba682f01e2f ("[SCSI] libcxgbi: common library for cxgb3i and cxgb4i")
> Signed-off-by: Ma Ke <make24@...as.ac.cn>
> ---
>  drivers/scsi/cxgbi/libcxgbi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
> index bf75940f2be1..6b0f1e8dac40 100644
> --- a/drivers/scsi/cxgbi/libcxgbi.c
> +++ b/drivers/scsi/cxgbi/libcxgbi.c
> @@ -670,6 +670,7 @@ cxgbi_check_route(struct sockaddr *dst_addr, int ifindex)
>  		"route to %pI4 :%u, ndev p#%d,%s, cdev 0x%p.\n",
>  		&daddr->sin_addr.s_addr, ntohs(daddr->sin_port),
>  			   port, ndev->name, cdev);
> +	dev_put(ndev);

After we call ip_dev_find can we hit one of the error path gotos like
the test for IFF_UP? If so you would leak the reference in those paths.

The ndev above looks like it could come from the ip_dev_find call when
IFF_LOOPBACK is set or it could come from dst_neigh_lookup call. For the
dst_neigh_lookup case we don't want to do a dev_put do we? If you do,
then we are leaking the reference in the goto error paths.


>  
>  	csk = cxgbi_sock_create(cdev);
>  	if (!csk) {


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ