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

fuse: fix leaked notify reply

2018-11-21T08:27:44+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 
Cc:  #v2.6.36
Signed-off-by: Greg Kroah-Hartman

fuse: set FR_SENT while locked

2018-11-21T08:27:40+00:00

commit 4c316f2f3ff315cb48efb7435621e5bfb81df96d upstream.

Otherwise fuse_dev_do_write() could come in and finish off the request, and
the set_bit(FR_SENT, ...) could trigger the WARN_ON(test_bit(FR_SENT, ...))
in request_end().

Signed-off-by: Miklos Szeredi 
Reported-by: syzbot+ef054c4d3f64cd7f7cec@syzkaller.appspotmai
Fixes: 46c34a348b0a ("fuse: no fc->lock for pqueue parts")
Cc:  # v4.2
Signed-off-by: Greg Kroah-Hartman

fuse: fix blocked_waitq wakeup

2018-11-21T08:27:40+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")
Cc:  # v3.10
Signed-off-by: Greg Kroah-Hartman

fuse: Fix use-after-free in fuse_dev_do_write()

2018-11-21T08:27:39+00:00

commit d2d2d4fb1f54eff0f3faa9762d84f6446a4bc5d0 upstream.

After we found req in request_find() and released the lock,
everything may happen with the req in parallel:

cpu0                              cpu1
fuse_dev_do_write()               fuse_dev_do_write()
  req = request_find(fpq, ...)    ...
  spin_unlock(&fpq->lock)         ...
  ...                             req = request_find(fpq, oh.unique)
  ...                             spin_unlock(&fpq->lock)
  queue_interrupt(&fc->iq, req);   ...
  ...                              ...
  ...                              ...
  request_end(fc, req);
    fuse_put_request(fc, req);
  ...                              queue_interrupt(&fc->iq, req);


Signed-off-by: Kirill Tkhai 
Signed-off-by: Miklos Szeredi 
Fixes: 46c34a348b0a ("fuse: no fc->lock for pqueue parts")
Cc:  # v4.2
Signed-off-by: Greg Kroah-Hartman

fuse: Fix use-after-free in fuse_dev_do_read()

2018-11-21T08:27:39+00:00

commit bc78abbd55dd28e2287ec6d6502b842321a17c87 upstream.

We may pick freed req in this way:

[cpu0]                                  [cpu1]
fuse_dev_do_read()                      fuse_dev_do_write()
   list_move_tail(&req->list, ...);     ...
   spin_unlock(&fpq->lock);             ...
   ...                                  request_end(fc, req);
   ...                                    fuse_put_request(fc, req);
   if (test_bit(FR_INTERRUPTED, ...))
         queue_interrupt(fiq, req);

Fix that by keeping req alive until we finish all manipulations.

Reported-by: syzbot+4e975615ca01f2277bdd@syzkaller.appspotmail.com
Signed-off-by: Kirill Tkhai 
Signed-off-by: Miklos Szeredi 
Fixes: 46c34a348b0a ("fuse: no fc->lock for pqueue parts")
Cc:  # v4.2
Signed-off-by: Greg Kroah-Hartman

fuse: Dont call set_page_dirty_lock() for ITER_BVEC pages for async_dio

2018-11-10T15:41:37+00:00

[ Upstream commit 61c12b49e1c9c77d7a1bcc161de540d0fd21cf0c ]

Commit 8fba54aebbdf ("fuse: direct-io: don't dirty ITER_BVEC pages") fixes
the ITER_BVEC page deadlock for direct io in fuse by checking in
fuse_direct_io(), whether the page is a bvec page or not, before locking
it.  However, this check is missed when the "async_dio" mount option is
enabled.  In this case, set_page_dirty_lock() is called from the req->end
callback in request_end(), when the fuse thread is returning from userspace
to respond to the read request.  This will cause the same deadlock because
the bvec condition is not checked in this path.

Here is the stack of the deadlocked thread, while returning from userspace:

[13706.656686] INFO: task glusterfs:3006 blocked for more than 120 seconds.
[13706.657808] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[13706.658788] glusterfs       D ffffffff816c80f0     0  3006      1
0x00000080
[13706.658797]  ffff8800d6713a58 0000000000000086 ffff8800d9ad7000
ffff8800d9ad5400
[13706.658799]  ffff88011ffd5cc0 ffff8800d6710008 ffff88011fd176c0
7fffffffffffffff
[13706.658801]  0000000000000002 ffffffff816c80f0 ffff8800d6713a78
ffffffff816c790e
[13706.658803] Call Trace:
[13706.658809]  [] ? bit_wait_io_timeout+0x80/0x80
[13706.658811]  [] schedule+0x3e/0x90
[13706.658813]  [] schedule_timeout+0x1b5/0x210
[13706.658816]  [] ? gup_pud_range+0x1db/0x1f0
[13706.658817]  [] ? kvm_clock_read+0x1e/0x20
[13706.658819]  [] ? kvm_clock_get_cycles+0x9/0x10
[13706.658822]  [] ? ktime_get+0x52/0xc0
[13706.658824]  [] io_schedule_timeout+0xa4/0x110
[13706.658826]  [] bit_wait_io+0x36/0x50
[13706.658828]  [] __wait_on_bit_lock+0x76/0xb0
[13706.658831]  [] ? lock_request+0x46/0x70 [fuse]
[13706.658834]  [] __lock_page+0xaa/0xb0
[13706.658836]  [] ? wake_atomic_t_function+0x40/0x40
[13706.658838]  [] set_page_dirty_lock+0x58/0x60
[13706.658841]  [] fuse_release_user_pages+0x58/0x70 [fuse]
[13706.658844]  [] ? fuse_aio_complete+0x190/0x190 [fuse]
[13706.658847]  [] fuse_aio_complete_req+0x29/0x90 [fuse]
[13706.658849]  [] request_end+0xd9/0x190 [fuse]
[13706.658852]  [] fuse_dev_do_write+0x336/0x490 [fuse]
[13706.658854]  [] fuse_dev_write+0x6e/0xa0 [fuse]
[13706.658857]  [] ? security_file_permission+0x23/0x90
[13706.658859]  [] do_iter_readv_writev+0x60/0x90
[13706.658862]  [] ? fuse_dev_splice_write+0x350/0x350
[fuse]
[13706.658863]  [] do_readv_writev+0x171/0x1f0
[13706.658866]  [] ? try_to_wake_up+0x210/0x210
[13706.658868]  [] vfs_writev+0x41/0x50
[13706.658870]  [] SyS_writev+0x56/0xf0
[13706.658872]  [] ? syscall_trace_leave+0xf1/0x160
[13706.658874]  [] system_call_fastpath+0x12/0x71

Fix this by making should_dirty a fuse_io_priv parameter that can be
checked in fuse_aio_complete_req().

Reported-by: Tiger Yang 
Signed-off-by: Ashish Samant 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Sasha Levin

fuse: Add missed unlock_page() to fuse_readpages_fill()

2018-09-05T07:18:39+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: Greg Kroah-Hartman

fuse: Fix oops at process_init_reply()

2018-09-05T07:18:39+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")
Cc:  # v3.19
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: umount should wait for all requests

2018-09-05T07:18:39+00:00

commit b8f95e5d13f5f0191dcb4b9113113d241636e7cb upstream.

fuse_abort_conn() does not guarantee that all async requests have actually
finished aborting (i.e. their ->end() function is called).  This could
actually result in still used inodes after umount.

Add a helper to wait until all requests are fully done.  This is done by
looking at the "num_waiting" counter.  When this counter drops to zero, we
can be sure that no more requests are outstanding.

Fixes: 0d8e84b0432b ("fuse: simplify request abort")
Cc:  # v4.2
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: fix unlocked access to processing queue

2018-09-05T07:18:39+00:00

commit 45ff350bbd9d0f0977ff270a0d427c71520c0c37 upstream.

fuse_dev_release() assumes that it's the only one referencing the
fpq->processing list, but that's not true, since fuse_abort_conn() can be
doing the same without any serialization between the two.

Fixes: c3696046beb3 ("fuse: separate pqueue for clones")
Cc:  # v4.2
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman