All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: linux-fsdevel@vger.kernel.org,
	syzbot+942d5390db2d9624ced8@syzkaller.appspotmail.com
Subject: Re: [PATCH] vfs_getxattr_alloc(): don't allocate buf on failure
Date: Tue, 2 Aug 2022 16:29:08 +0100	[thread overview]
Message-ID: <YulCxLl76A/vsu4/@ZenIV> (raw)
In-Reply-To: <Yuk+32FgLeu6koHV@ZenIV>

On Tue, Aug 02, 2022 at 04:12:31PM +0100, Al Viro wrote:
> On Tue, Aug 02, 2022 at 04:42:36PM +0200, Miklos Szeredi wrote:
> > Some callers of vfs_getxattr_alloc() assume that on failure the allocated
> > buffer does not need to be freed.
> > 
> > Callers could be fixed, but fixing the semantics of vfs_getxattr_alloc() is
> > simpler and makes sure that this class of bugs does not occur again.
> > 
> > Reported-and-tested-by: syzbot+942d5390db2d9624ced8@syzkaller.appspotmail.com
> > Fixes: 1601fbad2b14 ("xattr: define vfs_getxattr_alloc and vfs_xattr_cmp")
> > Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
> > ---
> >  fs/xattr.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/xattr.c b/fs/xattr.c
> > index e8dd03e4561e..1800cfa97411 100644
> > --- a/fs/xattr.c
> > +++ b/fs/xattr.c
> > @@ -383,7 +383,10 @@ vfs_getxattr_alloc(struct user_namespace *mnt_userns, struct dentry *dentry,
> >  	}
> >  
> >  	error = handler->get(handler, dentry, inode, name, value, error);
> > -	*xattr_value = value;
> > +	if (error < 0 && value != *xattr_value)
> > +		kfree(value);
> > +	else
> > +		*xattr_value = value;
> >  	return error;
> >  }
> 
> Think what happens if it had been called with non-NULL *xattr_value,
> found that it needed realloc, had krealloc() succeed (and free the
> original), only to fail in ->get().
> 
> Your variant will leave *xattr_value pointing to already freed
> object, with no way for the caller to tell that from failure before
> it got to krealloc().
> 
> IOW, that's unusable for callers with preallocated buffer - in
> particular, ones that call that thing in a loop.

FWIW, if we change calling conventions so that in some cases caller
need not kfree() whatever's in *xattr_value, about the only variant
I see is to have the damn thing freed and replaced with NULL on
*all* failure exits.  Might or might not make sense, not sure...

  reply	other threads:[~2022-08-02 15:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02 14:42 [PATCH] vfs_getxattr_alloc(): don't allocate buf on failure Miklos Szeredi
2022-08-02 15:12 ` Al Viro
2022-08-02 15:29   ` Al Viro [this message]
2022-08-03 13:24     ` Miklos Szeredi

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=YulCxLl76A/vsu4/@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=syzbot+942d5390db2d9624ced8@syzkaller.appspotmail.com \
    /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.