linux-stable.git/fs/fuse, branch v4.1.45

fuse: initialize the flock flag in fuse_file on allocation

2017-09-10T20:36:10+00:00

[ Upstream commit 68227c03cba84a24faf8a7277d2b1a03c8959c2c ]

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: Sasha Levin

fs: Give dentry to inode_change_ok() instead of inode

2016-12-23T13:56:35+00:00

[ Upstream commit 31051c85b5e2aaaf6315f74c72a732673632a905 ]

inode_change_ok() will be resposible for clearing capabilities and IMA
extended attributes and as such will need dentry. Give it as an argument
to inode_change_ok() instead of an inode. Also rename inode_change_ok()
to setattr_prepare() to better relect that it does also some
modifications in addition to checks.

References: CVE-2015-1350
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jan Kara 
Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin

fuse: Propagate dentry down to inode_change_ok()

2016-12-23T13:56:34+00:00

[ Upstream commit 62490330769c1ce5dcba3f1f3e8f4005e9b797e6 ]

To avoid clearing of capabilities or security related extended
attributes too early, inode_change_ok() will need to take dentry instead
of inode. Propagate it down to fuse_do_setattr().

References: CVE-2015-1350
Acked-by: Miklos Szeredi 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jan Kara 

Conflicts: Missing file_dentry() from d101a125954eae1d397adda94ca6319485a50493
Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin

fuse: direct-io: don't dirty ITER_BVEC pages

2016-10-02T16:50:39+00:00

[ Upstream commit 8fba54aebbdf1f999738121922e74bf796ad60ee ]

When reading from a loop device backed by a fuse file it deadlocks on
lock_page().

This is because the page is already locked by the read() operation done on
the loop device.  In this case we don't want to either lock the page or
dirty it.

So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors.

Reported-by: Sheng Yang 
Fixes: aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC")
Signed-off-by: Miklos Szeredi 
Cc:  # v4.1+
Reviewed-by: Sheng Yang 
Reviewed-by: Ashish Samant 
Tested-by: Sheng Yang 
Tested-by: Ashish Samant 
Signed-off-by: Sasha Levin

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

2016-08-20T03:07:58+00:00

[ Upstream commit 9446385f05c9af25fed53dbed3cc75763730be52 ]

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: Sasha Levin

fuse: fuse_flush must check mapping->flags for errors

2016-08-20T03:07:58+00:00

[ Upstream commit 9ebce595f63a407c5cec98f98f9da8459b73740a ]

fuse_flush() calls write_inode_now() that triggers writeback, but actual
writeback will happen later, on fuse_sync_writes(). If an error happens,
fuse_writepage_end() will set error bit in mapping->flags. So, we have to
check mapping->flags after fuse_sync_writes().

Signed-off-by: Maxim Patlasov 
Signed-off-by: Miklos Szeredi 
Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on")
Cc:  # v3.15+
Signed-off-by: Sasha Levin

fuse: fsync() did not return IO errors

2016-08-20T03:07:58+00:00

[ Upstream commit ac7f052b9e1534c8248f814b6f0068ad8d4a06d2 ]

Due to implementation of fuse writeback filemap_write_and_wait_range() does
not catch errors. We have to do this directly after fuse_sync_writes()

Signed-off-by: Alexey Kuznetsov 
Signed-off-by: Maxim Patlasov 
Signed-off-by: Miklos Szeredi 
Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on")
Cc:  # v3.15+
Signed-off-by: Sasha Levin

fuse: Add reference counting for fuse_io_priv

2016-04-18T12:50:57+00:00

[ Upstream commit 744742d692e37ad5c20630e57d526c8f2e2fe3c9 ]

The 'reqs' member of fuse_io_priv serves two purposes. First is to track
the number of oustanding async requests to the server and to signal that
the io request is completed. The second is to be a reference count on the
structure to know when it can be freed.

For sync io requests these purposes can be at odds.  fuse_direct_IO() wants
to block until the request is done, and since the signal is sent when
'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to
use the object after the userspace server has completed processing
requests. This leads to some handshaking and special casing that it
needlessly complicated and responsible for at least one race condition.

It's much cleaner and safer to maintain a separate reference count for the
object lifecycle and to let 'reqs' just be a count of outstanding requests
to the userspace server. Then we can know for sure when it is safe to free
the object without any handshaking or special cases.

The catch here is that most of the time these objects are stack allocated
and should not be freed. Initializing these objects with a single reference
that is never released prevents accidental attempts to free the objects.

Fixes: 9d5722b7777e ("fuse: handle synchronous iocbs internally")
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Seth Forshee 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Sasha Levin

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

2016-04-18T12:50:56+00:00

[ Upstream commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 ]

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")
Cc:  # 3.10+
Signed-off-by: Sasha Levin

fuse: break infinite loop in fuse_fill_write_pages()

2016-04-13T21:14:29+00:00

[ Upstream commit 3ca8138f014a913f98e6ef40e939868e1e9ea876 ]

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")
Cc: 
Signed-off-by: Sasha Levin