All of lore.kernel.org
 help / color / mirror / Atom feed
From: Navid Emamdoost <navid.emamdoost@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.com>,
	emamd001@umn.edu, kjlu@umn.edu, smccaman@umn.edu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udf: prevent memory leak in udf_new_inode
Date: Thu, 26 Sep 2019 22:02:37 -0500	[thread overview]
Message-ID: <20190927030237.GE22969@cs-dulles.cs.umn.edu> (raw)
In-Reply-To: <20190926080031.GB12013@quack2.suse.cz>

On Thu, Sep 26, 2019 at 10:00:31AM +0200, Jan Kara wrote:
> On Wed 25-09-19 23:24:08, Al Viro wrote:
> > On Wed, Sep 25, 2019 at 04:39:03PM -0500, Navid Emamdoost wrote:
> > > In udf_new_inode if either udf_new_block or insert_inode_locked fials
> > > the allocated memory for iinfo->i_ext.i_data should be released.
> > 
> > "... because of such-and-such reasons" part appears to be missing.
> > Why should it be released there?
> > 
> > > Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> > > ---
> > >  fs/udf/ialloc.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
> > > index 0adb40718a5d..b8ab3acab6b6 100644
> > > --- a/fs/udf/ialloc.c
> > > +++ b/fs/udf/ialloc.c
> > > @@ -86,6 +86,7 @@ struct inode *udf_new_inode(struct inode *dir, umode_t mode)
> > >  			      dinfo->i_location.partitionReferenceNum,
> > >  			      start, &err);
> > >  	if (err) {
> > > +		kfree(iinfo->i_ext.i_data);
> > >  		iput(inode);
> > >  		return ERR_PTR(err);
> > >  	}
> > 
> > Have you tested that?  Because it has all earmarks of double-free;
> > normal eviction pathway ought to free the damn thing.  <greps around
> > a bit>
> > 
> > Mind explaining what's to stop ->evict_inode (== udf_evict_inode) from
> > hitting
> >         kfree(iinfo->i_ext.i_data);
> > considering that this call of kfree() appears to be unconditional there?
> 
> Exactly. udf_evict_inode() is responsible for freeing iinfo->i_ext.i_data
> so the patch would result in double free.
> 
> 								Honza
Thanks for clarification.
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

      reply	other threads:[~2019-09-27  3:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 21:39 [PATCH] udf: prevent memory leak in udf_new_inode Navid Emamdoost
2019-09-25 22:24 ` Al Viro
2019-09-26  8:00   ` Jan Kara
2019-09-27  3:02     ` Navid Emamdoost [this message]

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=20190927030237.GE22969@cs-dulles.cs.umn.edu \
    --to=navid.emamdoost@gmail.com \
    --cc=emamd001@umn.edu \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=kjlu@umn.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smccaman@umn.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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.