qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: mszeredi@redhat.com, Daniel Berrange <berrange@redhat.com>,
	slp@redhat.com, qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	virtio-fs@redhat.com, P J P <ppandit@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>,
	vgoyal@redhat.com
Subject: Re: [PATCH v4 2/3] virtiofsd: optionally return inode pointer from lo_do_lookup()
Date: Thu, 4 Feb 2021 09:25:28 +0100	[thread overview]
Message-ID: <20210204092528.0f4b3200@bahia.lan> (raw)
In-Reply-To: <20210203170006.GK74271@stefanha-x1.localdomain>

[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]

On Wed, 3 Feb 2021 17:00:06 +0000
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> On Wed, Feb 03, 2021 at 03:20:14PM +0100, Greg Kurz wrote:
> > On Wed,  3 Feb 2021 11:37:18 +0000
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > 
> > > lo_do_lookup() finds an existing inode or allocates a new one. It
> > > increments nlookup so that the inode stays alive until the client
> > > releases it.
> > > 
> > > Existing callers don't need the struct lo_inode so the function doesn't
> > > return it. Extend the function to optionally return the inode. The next
> > > commit will need it.
> > > 
> > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > ---
> > >  tools/virtiofsd/passthrough_ll.c | 29 +++++++++++++++++++++--------
> > >  1 file changed, 21 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
> > > index e63cbd3fb7..c87a1f3d72 100644
> > > --- a/tools/virtiofsd/passthrough_ll.c
> > > +++ b/tools/virtiofsd/passthrough_ll.c
> > > @@ -831,11 +831,13 @@ static int do_statx(struct lo_data *lo, int dirfd, const char *pathname,
> > >  }
> > >  
> > >  /*
> > > - * Increments nlookup and caller must release refcount using
> > > - * lo_inode_put(&parent).
> > > + * Increments nlookup on the inode on success. unref_inode_lolocked() must be
> > > + * called eventually to decrement nlookup again. If inodep is non-NULL, the
> > > + * inode pointer is stored and the caller must call lo_inode_put().
> > >   */
> > >  static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name,
> > > -                        struct fuse_entry_param *e)
> > > +                        struct fuse_entry_param *e,
> > > +                        struct lo_inode **inodep)
> > >  {
> > >      int newfd;
> > >      int res;
> > > @@ -845,6 +847,10 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name,
> > >      struct lo_inode *inode = NULL;
> > >      struct lo_inode *dir = lo_inode(req, parent);
> > >  
> > > +    if (inodep) {
> > > +        *inodep = NULL;
> > > +    }
> > > +
> > 
> > Is this side-effect needed ? If lo_do_lookup() returns an error, it
> > rather seems that the caller shouldn't expect anything to be written
> > here, i.e. the content of *inodep still belongs to the caller and
> > whatever value it previously put in there (as patch 3/3 does) should
> > be preserved IMHO.
> > 
> > Apart from that LGTM.
> 
> I like this approach because it prevents accessing uninitialized memory
> in the caller:
> 
>   struct lo_inode *inode;
> 
>   if (lo_do_lookup(..., &inodep) != 0) {
>     goto err;
>   }
>   ...
> 
>   err:
>   lo_inode_put(&inode); <-- uninitialized in the error case!

My point is that it is the caller's business to ensure that inode
doesn't contain garbage if it is to be used irrespective of the
outcome of lo_do_lookup(). This is precisely what patch 3/3 does,
so I don't understand the ultimate purpose of nullifying the
inode pointer _again_ in lo_do_lookup()...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-02-04  8:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03 11:37 [PATCH v4 0/3] virtiofsd: prevent opening of special files (CVE-2020-35517) Stefan Hajnoczi
2021-02-03 11:37 ` [PATCH v4 1/3] virtiofsd: extract lo_do_open() from lo_open() Stefan Hajnoczi
2021-02-03 14:20   ` Greg Kurz
2021-02-03 14:47     ` Dr. David Alan Gilbert
2021-02-03 15:45       ` Greg Kurz
2021-02-03 17:47         ` Greg Kurz
2021-02-03 16:57       ` Stefan Hajnoczi
2021-02-03 11:37 ` [PATCH v4 2/3] virtiofsd: optionally return inode pointer from lo_do_lookup() Stefan Hajnoczi
2021-02-03 14:20   ` Greg Kurz
2021-02-03 17:00     ` Stefan Hajnoczi
2021-02-04  8:25       ` Greg Kurz [this message]
2021-02-04  9:45         ` Stefan Hajnoczi
2021-02-04 11:19           ` Greg Kurz
2021-02-03 11:37 ` [PATCH v4 3/3] virtiofsd: prevent opening of special files (CVE-2020-35517) Stefan Hajnoczi
2021-02-03 15:28   ` Vivek Goyal
2021-02-03 16:02     ` Greg Kurz
2021-02-03 16:08       ` Vivek Goyal
2021-02-03 17:05         ` Stefan Hajnoczi
2021-02-03 18:05           ` Dr. David Alan Gilbert
2021-02-03 21:14           ` Vivek Goyal
2021-02-04  9:47             ` Stefan Hajnoczi
2021-02-03 15:57   ` Greg Kurz
2021-02-03 17:06     ` Stefan Hajnoczi
2021-02-03 11:46 ` [PATCH v4 0/3] " no-reply

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=20210204092528.0f4b3200@bahia.lan \
    --to=groug@kaod.org \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mszeredi@redhat.com \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).