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: <20210504141435.GA24514@ard0534>
Date:   Tue, 4 May 2021 15:14:35 +0100
From:   Khaled Romdhani <khaledromdhani216@...il.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     sfrench@...ba.org, linux-cifs@...r.kernel.org,
        samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH-next] fs/cifs: Fix resource leak

On Tue, May 04, 2021 at 04:44:45PM +0300, Dan Carpenter wrote:
> On Tue, May 04, 2021 at 01:43:43PM +0100, Khaled ROMDHANI wrote:
> > The -EIO error return path is leaking memory allocated
> > to page. Fix this by invoking the free_dentry_path before
> > the return.
> > 
> > Addresses-Coverity: ("Resource leak")
> > Signed-off-by: Khaled ROMDHANI <khaledromdhani216@...il.com>
> 
> Add a Fixes tag.
> 
> Fixes: 583248493f78 ("cifs: add shutdown support")
>

Yes, I will add a Fixes tag.

> > ---
> >  fs/cifs/link.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/cifs/link.c b/fs/cifs/link.c
> > index 1cbe7ec73728..1485c6095ba1 100644
> > --- a/fs/cifs/link.c
> > +++ b/fs/cifs/link.c
> > @@ -686,8 +686,10 @@ cifs_symlink(struct user_namespace *mnt_userns, struct inode *inode,
> >  	void *page = alloc_dentry_path();
> >  	struct inode *newinode = NULL;
> >  
> > -	if (unlikely(cifs_forced_shutdown(cifs_sb)))
> > +	if (unlikely(cifs_forced_shutdown(cifs_sb))) {
> > +		free_dentry_path(page);
> >  		return -EIO;
> > +	}
> 
> Better to move the allocation here.  Avoid calling functions which can
> fail in the declaration block.  Better to test for NULL directly instead
> of hiding the test inside the build_path_from_dentry() function.
> 
> 	page = alloc_dentry_path();
> 	if (!page)
> 		return -ENOMEM;
> 
> The error handling in this function is slightly unweildy...
> 
> regards,
> dan carpenter
>

Yes, it would be better to move the allocation...
I will send a V2.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ