linux-stable.git/fs/fuse, branch linux-3.10.y

fuse: initialize the flock flag in fuse_file on allocation

2017-11-01T21:12:44+00:00

commit 68227c03cba84a24faf8a7277d2b1a03c8959c2c upstream.

Before the patch, the flock flag could remain uninitialized for the
lifespan of the fuse_file allocation. Unless set to true in
fuse_file_flock(), it would remain in an indeterminate state until read in
an if statement in fuse_release_common(). This could consequently lead to
taking an unexpected branch in the code.

The bug was discovered by a runtime instrumentation designed to detect use
of uninitialized memory in the kernel.

Signed-off-by: Mateusz Jurczyk 
Fixes: 37fb3a30b462 ("fuse: fix flock")
Cc:  # v3.1+
Signed-off-by: Miklos Szeredi 
Signed-off-by: Willy Tarreau

fuse: add missing FR_FORCE

2017-06-07T22:47:01+00:00

commit 2e38bea99a80eab408adee27f873a188d57b76cb upstream.

fuse_file_put() was missing the "force" flag for the RELEASE request when
sending synchronously (fuseblk).

If this flag is not set, then a sync request may be interrupted before it
is dequeued by the userspace filesystem.  In this case the OPEN won't be
balanced with a RELEASE.

[js] force is a variable, not a bit

Signed-off-by: Miklos Szeredi 
Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem")
Signed-off-by: Jiri Slaby 
Signed-off-by: Willy Tarreau

fuse: do not use iocb after it may have been freed

2017-06-07T22:46:57+00:00

commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 upstream.

There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an
iocb that could have been freed if async io has already completed.  The fix
in this case is simple and obvious: cache the result before starting io.

It was discovered by KASan:

Kernel: ==================================================================
Kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390

Signed-off-by: Robert Doebbelin 
Signed-off-by: Miklos Szeredi 
Fixes: bcba24ccdc82 ("fuse: enable asynchronous processing direct IO")
Signed-off-by: Jan Kara 
Signed-off-by: Willy Tarreau

fuse: fix wrong assignment of ->flags in fuse_send_init()

2016-08-27T09:40:35+00:00

commit 9446385f05c9af25fed53dbed3cc75763730be52 upstream.

FUSE_HAS_IOCTL_DIR should be assigned to ->flags, it may be a typo.

Signed-off-by: Wei Fang 
Signed-off-by: Miklos Szeredi 
Fixes: 69fe05c90ed5 ("fuse: add missing INIT flags")
Cc: 
Signed-off-by: Willy Tarreau

fuse: break infinite loop in fuse_fill_write_pages()

2016-02-25T19:57:48+00:00

commit 3ca8138f014a913f98e6ef40e939868e1e9ea876 upstream.

I got a report about unkillable task eating CPU. Further
investigation shows, that the problem is in the fuse_fill_write_pages()
function. If iov's first segment has zero length, we get an infinite
loop, because we never reach iov_iter_advance() call.

Fix this by calling iov_iter_advance() before repeating an attempt to
copy data from userspace.

A similar problem is described in 124d3b7041f ("fix writev regression:
pan hanging unkillable and un-straceable"). If zero-length segmend
is followed by segment with invalid address,
iov_iter_fault_in_readable() checks only first segment (zero-length),
iov_iter_copy_from_user_atomic() skips it, fails at second and
returns zero -> goto again without skipping zero-length segment.

Patch calls iov_iter_advance() before goto again: we'll skip zero-length
segment at second iteraction and iov_iter_fault_in_readable() will detect
invalid address.

Special thanks to Konstantin Khlebnikov, who helped a lot with the commit
description.

Cc: Andrew Morton 
Cc: Maxim Patlasov 
Cc: Konstantin Khlebnikov 
Signed-off-by: Roman Gushchin 
Signed-off-by: Miklos Szeredi 
Fixes: ea9b9907b82a ("fuse: implement perform_write")
Signed-off-by: Greg Kroah-Hartman

fuse: initialize fc->release before calling it

2015-08-03T16:29:46+00:00

commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream.

fc->release is called from fuse_conn_put() which was used in the error
cleanup before fc->release was initialized.

[Jeremiah Mahler : assign fc->release after calling
fuse_conn_init(fc) instead of before.]

Signed-off-by: Miklos Szeredi 
Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()")
Signed-off-by: Greg Kroah-Hartman

fuse: notify: don't move pages

2015-03-26T14:00:57+00:00

commit 0d2783626a53d4c922f82d51fa675cb5d13f0d36 upstream.

fuse_try_move_page() is not prepared for replacing pages that have already
been read.

Reported-by: Al Viro 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: set stolen page uptodate

2015-03-26T14:00:57+00:00

commit aa991b3b267e24f578bac7b09cc57579b660304b upstream.

Regular pipe buffers' ->steal method (generic_pipe_buf_steal()) doesn't set
PG_uptodate.

Don't warn on this condition, just set the uptodate flag.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: handle large user and group ID

2014-07-28T15:00:02+00:00

commit 233a01fa9c4c7c41238537e8db8434667ff28a2f upstream.

If the number in "user_id=N" or "group_id=N" mount options was larger than
INT_MAX then fuse returned EINVAL.

Fix this to handle all valid uid/gid values.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: fix pipe_buf_operations

2014-02-13T21:47:59+00:00

commit 28a625cbc2a14f17b83e47ef907b2658576a32aa upstream.

Having this struct in module memory could Oops when if the module is
unloaded while the buffer still persists in a pipe.

Since sock_pipe_buf_ops is essentially the same as fuse_dev_pipe_buf_steal
merge them into nosteal_pipe_buf_ops (this is the same as
default_pipe_buf_ops except stealing the page from the buffer is not
allowed).

Reported-by: Al Viro 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman