All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Daniel Berrange <berrange@redhat.com>,
	Sergio Lopez Pascual <slp@redhat.com>, Greg Kurz <groug@kaod.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	virtio-fs-list <virtio-fs@redhat.com>, Alex Xu <alex@alxu.ca>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	P J P <ppandit@redhat.com>, Laszlo Ersek <lersek@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v3] virtiofsd: prevent opening of special files (CVE-2020-35517)
Date: Wed, 27 Jan 2021 14:14:30 +0000	[thread overview]
Message-ID: <20210127141430.GA310142@stefanha-x1.localdomain> (raw)
In-Reply-To: <CAOssrKfY7zDOH3NNbtyARHMCdJJN1tKQJri8ec=igjBf=K6Dog@mail.gmail.com>

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

On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
> On Wed, Jan 27, 2021 at 12:21 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
>               }
> > @@ -1654,9 +1677,11 @@ static void update_open_flags(int writeback, int allow_direct_io,
> >  static void lo_create(fuse_req_t req, fuse_ino_t parent, const char *name,
> >                        mode_t mode, struct fuse_file_info *fi)
> >  {
> > +    int open_flags = (fi->flags | O_CREAT) & ~O_NOFOLLOW;
> >      int fd;
> >      struct lo_data *lo = lo_data(req);
> >      struct lo_inode *parent_inode;
> > +    struct lo_inode *existing_inode = NULL;
> >      struct fuse_entry_param e;
> >      int err;
> >      struct lo_cred old = {};
> > @@ -1682,11 +1707,23 @@ static void lo_create(fuse_req_t req, fuse_ino_t parent, const char *name,
> >
> >      update_open_flags(lo->writeback, lo->allow_direct_io, fi);
> >
> > -    fd = openat(parent_inode->fd, name, (fi->flags | O_CREAT) & ~O_NOFOLLOW,
> > -                mode);
> > +    /* First, try to create a new file but don't open existing files */
> > +    fd = openat(parent_inode->fd, name, open_flags | O_EXCL, mode);
> >      err = fd == -1 ? errno : 0;
> > +
> >      lo_restore_cred(&old);
> >
> > +    /* Second, open existing files if O_EXCL was not specified */
> > +    if (err == EEXIST && !(fi->flags & O_EXCL)) {
> > +        existing_inode = lookup_name(req, parent, name);
> > +        if (existing_inode) {
> > +            fd = lo_inode_open(lo, existing_inode, open_flags);
> > +            if (fd < 0) {
> > +                err = -fd;
> > +            }
> > +        }
> > +    }
> > +
> >      if (!err) {
> >          ssize_t fh;
> 
> It's more of a mess than I thought.
> 
> The problem here is there can also be a race between the open and the
> subsequent lo_do_lookup().
> 
> At this point it's probably enough to verify that fuse_entry_param
> refers to the same object as the fh (using fstat and comparing st_dev
> and st_ino).

Can you describe the race in detail? FUSE_CREATE vs FUSE_OPEN?
FUSE_CREATE vs FUSE_CREATE?

> Also O_CREAT open is not supposed to return ENOENT, so failure to open
> without O_CREAT (race between O_CREAT open and plain open) should at
> least translate error to ESTALE or EIO.

Thanks, will fix.

Sstefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Daniel Berrange <berrange@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	virtio-fs-list <virtio-fs@redhat.com>, Alex Xu <alex@alxu.ca>,
	P J P <ppandit@redhat.com>, Laszlo Ersek <lersek@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] [PATCH v3] virtiofsd: prevent opening of special files (CVE-2020-35517)
Date: Wed, 27 Jan 2021 14:14:30 +0000	[thread overview]
Message-ID: <20210127141430.GA310142@stefanha-x1.localdomain> (raw)
In-Reply-To: <CAOssrKfY7zDOH3NNbtyARHMCdJJN1tKQJri8ec=igjBf=K6Dog@mail.gmail.com>

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

On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
> On Wed, Jan 27, 2021 at 12:21 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
>               }
> > @@ -1654,9 +1677,11 @@ static void update_open_flags(int writeback, int allow_direct_io,
> >  static void lo_create(fuse_req_t req, fuse_ino_t parent, const char *name,
> >                        mode_t mode, struct fuse_file_info *fi)
> >  {
> > +    int open_flags = (fi->flags | O_CREAT) & ~O_NOFOLLOW;
> >      int fd;
> >      struct lo_data *lo = lo_data(req);
> >      struct lo_inode *parent_inode;
> > +    struct lo_inode *existing_inode = NULL;
> >      struct fuse_entry_param e;
> >      int err;
> >      struct lo_cred old = {};
> > @@ -1682,11 +1707,23 @@ static void lo_create(fuse_req_t req, fuse_ino_t parent, const char *name,
> >
> >      update_open_flags(lo->writeback, lo->allow_direct_io, fi);
> >
> > -    fd = openat(parent_inode->fd, name, (fi->flags | O_CREAT) & ~O_NOFOLLOW,
> > -                mode);
> > +    /* First, try to create a new file but don't open existing files */
> > +    fd = openat(parent_inode->fd, name, open_flags | O_EXCL, mode);
> >      err = fd == -1 ? errno : 0;
> > +
> >      lo_restore_cred(&old);
> >
> > +    /* Second, open existing files if O_EXCL was not specified */
> > +    if (err == EEXIST && !(fi->flags & O_EXCL)) {
> > +        existing_inode = lookup_name(req, parent, name);
> > +        if (existing_inode) {
> > +            fd = lo_inode_open(lo, existing_inode, open_flags);
> > +            if (fd < 0) {
> > +                err = -fd;
> > +            }
> > +        }
> > +    }
> > +
> >      if (!err) {
> >          ssize_t fh;
> 
> It's more of a mess than I thought.
> 
> The problem here is there can also be a race between the open and the
> subsequent lo_do_lookup().
> 
> At this point it's probably enough to verify that fuse_entry_param
> refers to the same object as the fh (using fstat and comparing st_dev
> and st_ino).

Can you describe the race in detail? FUSE_CREATE vs FUSE_OPEN?
FUSE_CREATE vs FUSE_CREATE?

> Also O_CREAT open is not supposed to return ENOENT, so failure to open
> without O_CREAT (race between O_CREAT open and plain open) should at
> least translate error to ESTALE or EIO.

Thanks, will fix.

Sstefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-01-27 14:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 11:21 [PATCH v3] virtiofsd: prevent opening of special files (CVE-2020-35517) Stefan Hajnoczi
2021-01-27 11:21 ` [Virtio-fs] " Stefan Hajnoczi
2021-01-27 13:01 ` Miklos Szeredi
2021-01-27 13:01   ` [Virtio-fs] " Miklos Szeredi
2021-01-27 14:14   ` Stefan Hajnoczi [this message]
2021-01-27 14:14     ` Stefan Hajnoczi
2021-01-27 14:27     ` Miklos Szeredi
2021-01-27 14:27       ` [Virtio-fs] " Miklos Szeredi
2021-01-28 15:32       ` Stefan Hajnoczi
2021-01-28 15:32         ` [Virtio-fs] " Stefan Hajnoczi
2021-01-27 15:23     ` Greg Kurz
2021-01-27 15:23       ` [Virtio-fs] " Greg Kurz
2021-01-28 16:11       ` Stefan Hajnoczi
2021-01-28 16:11         ` [Virtio-fs] " Stefan Hajnoczi
2021-01-28 17:44 ` Greg Kurz
2021-01-28 17:44   ` [Virtio-fs] " Greg Kurz
2021-02-01 17:14   ` Stefan Hajnoczi
2021-02-01 17:14     ` [Virtio-fs] " Stefan Hajnoczi
2021-02-01 18:22     ` Stefan Hajnoczi
2021-02-01 18:22       ` Stefan Hajnoczi
2021-02-05 15:29       ` Chirantan Ekbote
2021-02-05 15:29         ` Chirantan Ekbote
2021-02-01 19:26     ` Greg Kurz
2021-02-01 19:26       ` [Virtio-fs] " Greg Kurz

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=20210127141430.GA310142@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=alex@alxu.ca \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=groug@kaod.org \
    --cc=lersek@redhat.com \
    --cc=mszeredi@redhat.com \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@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 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.