On Tue, Feb 2, 2021 at 3:22 AM Stefan Hajnoczi wrote:
> Hi Chirantan,
> I wanted to bring this CVE to your attention because the discussion has
> revealed a number of other issues (not necessarily security issues) in
> virtiofsd that may also be present in other virtio-fs daemon
> implementations.
On Mon, 1 Feb 2021 17:14:40 +
Stefan Hajnoczi wrote:
> On Thu, Jan 28, 2021 at 06:44:16PM +0100, Greg Kurz wrote:
> > On Wed, 27 Jan 2021 11:21:31 +
> > Stefan Hajnoczi wrote:
> >
> > > A well-behaved FUSE client does not attempt to open special files with
> > > FUSE_OPEN because they a
On Mon, Feb 01, 2021 at 05:14:40PM +, Stefan Hajnoczi wrote:
> On Thu, Jan 28, 2021 at 06:44:16PM +0100, Greg Kurz wrote:
> > On Wed, 27 Jan 2021 11:21:31 +
> > Stefan Hajnoczi wrote:
> >
> > > A well-behaved FUSE client does not attempt to open special files with
> > > FUSE_OPEN because
On Thu, Jan 28, 2021 at 06:44:16PM +0100, Greg Kurz wrote:
> On Wed, 27 Jan 2021 11:21:31 +
> Stefan Hajnoczi wrote:
>
> > A well-behaved FUSE client does not attempt to open special files with
> > FUSE_OPEN because they are handled on the client side (e.g. device nodes
> > are handled by cli
On Wed, 27 Jan 2021 11:21:31 +
Stefan Hajnoczi wrote:
> A well-behaved FUSE client does not attempt to open special files with
> FUSE_OPEN because they are handled on the client side (e.g. device nodes
> are handled by client-side device drivers).
>
> The check to prevent virtiofsd from open
On Wed, Jan 27, 2021 at 04:23:32PM +0100, Greg Kurz wrote:
> On Wed, 27 Jan 2021 14:14:30 +
> Stefan Hajnoczi wrote:
>
> > On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
> > > On Wed, Jan 27, 2021 at 12:21 PM Stefan Hajnoczi
> > > wrote:
> > > }
> > > > @@ -16
On Wed, Jan 27, 2021 at 03:27:23PM +0100, Miklos Szeredi wrote:
> On Wed, Jan 27, 2021 at 3:14 PM Stefan Hajnoczi wrote:
> >
> > On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
>
> > > The problem here is there can also be a race between the open and the
> > > subsequent lo_do_loo
On Wed, 27 Jan 2021 14:14:30 +
Stefan Hajnoczi wrote:
> On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
> > On Wed, Jan 27, 2021 at 12:21 PM Stefan Hajnoczi
> > wrote:
> > }
> > > @@ -1654,9 +1677,11 @@ static void update_open_flags(int writeback, int
> > > al
On Wed, Jan 27, 2021 at 3:14 PM Stefan Hajnoczi wrote:
>
> On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
> > 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_
On Wed, Jan 27, 2021 at 02:01:54PM +0100, Miklos Szeredi wrote:
> On Wed, Jan 27, 2021 at 12:21 PM Stefan Hajnoczi 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
On Wed, Jan 27, 2021 at 12:21 PM Stefan Hajnoczi 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
A well-behaved FUSE client does not attempt to open special files with
FUSE_OPEN because they are handled on the client side (e.g. device nodes
are handled by client-side device drivers).
The check to prevent virtiofsd from opening special files is missing in
a few cases, most notably FUSE_OPEN. A
12 matches
Mail list logo
