linux-stable.git/fs/fuse, branch v3.16.65

fuse: continue to send FUSE_RELEASEDIR when FUSE_OPEN returns ENOSYS

2019-02-11T17:54:24+00:00

commit 2e64ff154ce6ce9a8dc0f9556463916efa6ff460 upstream.

When FUSE_OPEN returns ENOSYS, the no_open bit is set on the connection.

Because the FUSE_RELEASE and FUSE_RELEASEDIR paths share code, this
incorrectly caused the FUSE_RELEASEDIR request to be dropped and never sent
to userspace.

Pass an isdir bool to distinguish between FUSE_RELEASE and FUSE_RELEASEDIR
inside of fuse_file_put.

Fixes: 7678ac50615d ("fuse: support clients that don't implement 'open'")
Signed-off-by: Chad Austin 
Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

fuse: cleanup fuse_file refcounting

2019-02-11T17:54:24+00:00

commit 267d84449f52349ee252db684ed95ede18e51744 upstream.

struct fuse_file is stored in file->private_data.  Make this always be a
counting reference for consistency.

This also allows fuse_sync_release() to call fuse_file_put() instead of
partially duplicating its functionality.

Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16: force and background flags are bitfields]
Signed-off-by: Ben Hutchings

fuse: fix leaked notify reply

2019-02-11T17:53:56+00:00

commit 7fabaf303458fcabb694999d6fa772cc13d4e217 upstream.

fuse_request_send_notify_reply() may fail if the connection was reset for
some reason (e.g. fs was unmounted).  Don't leak request reference in this
case.  Besides leaking memory, this resulted in fc->num_waiting not being
decremented and hence fuse_wait_aborted() left in a hanging and unkillable
state.

Fixes: 2d45ba381a74 ("fuse: add retrieve request")
Fixes: b8f95e5d13f5 ("fuse: umount should wait for all requests")
Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c37b@syzkaller.appspotmail.com
Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings

fuse: fix blocked_waitq wakeup

2019-02-11T17:53:23+00:00

commit 908a572b80f6e9577b45e81b3dfe2e22111286b8 upstream.

Using waitqueue_active() is racy.  Make sure we issue a wake_up()
unconditionally after storing into fc->blocked.  After that it's okay to
optimize with waitqueue_active() since the first wake up provides the
necessary barrier for all waiters, not the just the woken one.

Signed-off-by: Miklos Szeredi 
Fixes: 3c18ef8117f0 ("fuse: optimize wake_up")
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

fuse: Add missed unlock_page() to fuse_readpages_fill()

2018-12-16T22:08:26+00:00

commit 109728ccc5933151c68d1106e4065478a487a323 upstream.

The above error path returns with page unlocked, so this place seems also
to behave the same.

Fixes: f8dbdf81821b ("fuse: rework fuse_readpages()")
Signed-off-by: Kirill Tkhai 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings

fuse: Don't access pipe->buffers without pipe_lock()

2018-12-16T22:08:26+00:00

commit a2477b0e67c52f4364a47c3ad70902bc2a61bd4c upstream.

fuse_dev_splice_write() reads pipe->buffers to determine the size of
'bufs' array before taking the pipe_lock(). This is not safe as
another thread might change the 'pipe->buffers' between the allocation
and taking the pipe_lock(). So we end up with too small 'bufs' array.

Move the bufs allocations inside pipe_lock()/pipe_unlock() to fix this.

Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device")
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

fuse: Fix oops at process_init_reply()

2018-12-16T22:08:26+00:00

commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream.

syzbot is hitting NULL pointer dereference at process_init_reply().
This is because deactivate_locked_super() is called before response for
initial request is processed.

Fix this by aborting and waiting for all requests (including FUSE_INIT)
before resetting fc->sb.

Original patch by Tetsuo Handa .

Reported-by: syzbot 
Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT")
Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16:
 - Drop second argument to fuse_abort_conn()
 - fuse_wait_aborted() is not needed]
Signed-off-by: Ben Hutchings

fuse: flush requests on umount

2018-12-16T22:08:25+00:00

commit 580640ba5d331eb5631a5de46941c98f5ed90886 upstream.

Use fuse_abort_conn() instead of fuse_conn_kill() in fuse_put_super().
This flushes and aborts requests still on any queues.  But since we've
already reset fc->connected, those requests would not be useful anyway and
would be flushed when the fuse device is closed.

Next patches will rely on requests being flushed before the superblock is
destroyed.

Use fuse_abort_conn() in cuse_process_init_reply() too, since it makes no
difference there, and we can get rid of fuse_conn_kill().

Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings

fuse: don't wake up reserved req in fuse_conn_kill()

2018-12-16T22:08:25+00:00

commit 0c4dd4ba1426c599072511dcf95a15ee5e12725b upstream.

Waking up reserved_req_waitq from fuse_conn_kill() doesn't make sense since
we aren't chaging ff->reserved_req here, which is what this waitqueue
signals.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings

fuse: don't keep dead fuse_conn at fuse_fill_super().

2018-11-20T18:05:06+00:00

commit 543b8f8662fe6d21f19958b666ab0051af9db21a upstream.

syzbot is reporting use-after-free at fuse_kill_sb_blk() [1].
Since sb->s_fs_info field is not cleared after fc was released by
fuse_conn_put() when initialization failed, fuse_kill_sb_blk() finds
already released fc and tries to hold the lock. Fix this by clearing
sb->s_fs_info field after calling fuse_conn_put().

[1] https://syzkaller.appspot.com/bug?id=a07a680ed0a9290585ca424546860464dd9658db

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Fixes: 3b463ae0c626 ("fuse: invalidation reverse calls")
Cc: John Muir 
Cc: Csaba Henk 
Cc: Anand Avati 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings