linux-stable.git/fs/fuse/dev.c, 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: 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

fuse: fix double request_end()

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

commit 87114373ea507895a62afb10d2910bd9adac35a8 upstream.

Refcounting of request is broken when fuse_abort_conn() is called and
request is on the fpq->io list:

 - ref is taken too late
 - then it is not dropped

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

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

2018-09-05T07:18:38+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 
Cc:  # v2.6.35
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: fix use after free issue in fuse_dev_do_read()

2017-02-23T16:43:09+00:00

commit 6ba4d2722d06960102c981322035239cd66f7316 upstream.

There is a potential race between fuse_dev_do_write()
and request_wait_answer() contexts as shown below:

TASK 1:
__fuse_request_send():
  |--spin_lock(&fiq->waitq.lock);
  |--queue_request();
  |--spin_unlock(&fiq->waitq.lock);
  |--request_wait_answer():
       |--if (test_bit(FR_SENT, &req->flags))
       
                                   TASK 2:
                                   fuse_dev_do_write():
                                     |--clears bit FR_SENT,
                                     |--request_end():
                                        |--sets bit FR_FINISHED
                                        |--spin_lock(&fiq->waitq.lock);
                                        |--list_del_init(&req->intr_entry);
                                        |--spin_unlock(&fiq->waitq.lock);
                                        |--fuse_put_request();
       |--queue_interrupt();
       
            |--wake_up_locked(&fiq->waitq);
       |--wait_event_freezable();
       

Now, the next fuse_dev_do_read(), see interrupts list is not empty
and then calls fuse_read_interrupt() which tries to access the request
which is already free'd and gets the below crash:

[11432.401266] Unable to handle kernel paging request at virtual address
6b6b6b6b6b6b6b6b
...
[11432.418518] Kernel BUG at ffffff80083720e0
[11432.456168] PC is at __list_del_entry+0x6c/0xc4
[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
...
[11432.679999] [] __list_del_entry+0x6c/0xc4
[11432.687794] [] fuse_dev_do_read+0x1ac/0x474
[11432.693180] [] fuse_dev_read+0x6c/0x78
[11432.699082] [] __vfs_read+0xc0/0xe8
[11432.704459] [] vfs_read+0x90/0x108
[11432.709406] [] SyS_read+0x58/0x94

As FR_FINISHED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().

Signed-off-by: Sahitya Tummala 
Signed-off-by: Miklos Szeredi 
Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
Signed-off-by: Greg Kroah-Hartman