1. 15 1月, 2020 1 次提交
  2. 13 12月, 2019 2 次提交
  3. 21 11月, 2019 1 次提交
  4. 06 11月, 2019 2 次提交
  5. 12 10月, 2019 1 次提交
  6. 05 10月, 2019 2 次提交
    • E
      fuse: fix deadlock with aio poll and fuse_iqueue::waitq.lock · 5bead06b
      Eric Biggers 提交于
      [ Upstream commit 76e43c8ccaa35c30d5df853013561145a0f750a5 ]
      
      When IOCB_CMD_POLL is used on the FUSE device, aio_poll() disables IRQs
      and takes kioctx::ctx_lock, then fuse_iqueue::waitq.lock.
      
      This may have to wait for fuse_iqueue::waitq.lock to be released by one
      of many places that take it with IRQs enabled.  Since the IRQ handler
      may take kioctx::ctx_lock, lockdep reports that a deadlock is possible.
      
      Fix it by protecting the state of struct fuse_iqueue with a separate
      spinlock, and only accessing fuse_iqueue::waitq using the versions of
      the waitqueue functions which do IRQ-safe locking internally.
      
      Reproducer:
      
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <sys/mount.h>
      	#include <sys/stat.h>
      	#include <sys/syscall.h>
      	#include <unistd.h>
      	#include <linux/aio_abi.h>
      
      	int main()
      	{
      		char opts[128];
      		int fd = open("/dev/fuse", O_RDWR);
      		aio_context_t ctx = 0;
      		struct iocb cb = { .aio_lio_opcode = IOCB_CMD_POLL, .aio_fildes = fd };
      		struct iocb *cbp = &cb;
      
      		sprintf(opts, "fd=%d,rootmode=040000,user_id=0,group_id=0", fd);
      		mkdir("mnt", 0700);
      		mount("foo",  "mnt", "fuse", 0, opts);
      		syscall(__NR_io_setup, 1, &ctx);
      		syscall(__NR_io_submit, ctx, 1, &cbp);
      	}
      
      Beginning of lockdep output:
      
      	=====================================================
      	WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
      	5.3.0-rc5 #9 Not tainted
      	-----------------------------------------------------
      	syz_fuse/135 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      	000000003590ceda (&fiq->waitq){+.+.}, at: spin_lock include/linux/spinlock.h:338 [inline]
      	000000003590ceda (&fiq->waitq){+.+.}, at: aio_poll fs/aio.c:1751 [inline]
      	000000003590ceda (&fiq->waitq){+.+.}, at: __io_submit_one.constprop.0+0x203/0x5b0 fs/aio.c:1825
      
      	and this task is already holding:
      	0000000075037284 (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq include/linux/spinlock.h:363 [inline]
      	0000000075037284 (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll fs/aio.c:1749 [inline]
      	0000000075037284 (&(&ctx->ctx_lock)->rlock){..-.}, at: __io_submit_one.constprop.0+0x1f4/0x5b0 fs/aio.c:1825
      	which would create a new lock dependency:
      	 (&(&ctx->ctx_lock)->rlock){..-.} -> (&fiq->waitq){+.+.}
      
      	but this new dependency connects a SOFTIRQ-irq-safe lock:
      	 (&(&ctx->ctx_lock)->rlock){..-.}
      
      	[...]
      
      Reported-by: syzbot+af05535bb79520f95431@syzkaller.appspotmail.com
      Reported-by: syzbot+d86c4426a01f60feddc7@syzkaller.appspotmail.com
      Fixes: bfe4037e ("aio: implement IOCB_CMD_POLL")
      Cc: <stable@vger.kernel.org> # v4.19+
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5bead06b
    • V
      fuse: fix missing unlock_page in fuse_writepage() · ad411629
      Vasily Averin 提交于
      commit d5880c7a8620290a6c90ced7a0e8bd0ad9419601 upstream.
      
      unlock_page() was missing in case of an already in-flight write against the
      same page.
      Signed-off-by: NVasily Averin <vvs@virtuozzo.com>
      Fixes: ff17be08 ("fuse: writepage: skip already in flight")
      Cc: <stable@vger.kernel.org> # v3.13
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad411629
  7. 15 6月, 2019 1 次提交
    • K
      fuse: retrieve: cap requested size to negotiated max_write · ae35c325
      Kirill Smelkov 提交于
      [ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
      
      FUSE filesystem server and kernel client negotiate during initialization
      phase, what should be the maximum write size the client will ever issue.
      Correspondingly the filesystem server then queues sys_read calls to read
      requests with buffer capacity large enough to carry request header + that
      max_write bytes. A filesystem server is free to set its max_write in
      anywhere in the range between [1*page, fc->max_pages*page]. In particular
      go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages
      corresponds to 128K. Libfuse also allows users to configure max_write, but
      by default presets it to possible maximum.
      
      If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we
      allow to retrieve more than max_write bytes, corresponding prepared
      NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the
      filesystem server, in full correspondence with server/client contract, will
      be only queuing sys_read with ~max_write buffer capacity, and
      fuse_dev_do_read throws away requests that cannot fit into server request
      buffer. In turn the filesystem server could get stuck waiting indefinitely
      for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is
      understood by clients as that NOTIFY_REPLY was queued and will be sent
      back.
      
      Cap requested size to negotiate max_write to avoid the problem.  This
      aligns with the way NOTIFY_RETRIEVE handler works, which already
      unconditionally caps requested retrieve size to fuse_conn->max_pages.  This
      way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than
      was originally requested.
      
      Please see [1] for context where the problem of stuck filesystem was hit
      for real, how the situation was traced and for more involving patch that
      did not make it into the tree.
      
      [1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
      [2] https://github.com/hanwen/go-fuseSigned-off-by: NKirill Smelkov <kirr@nexedi.com>
      Cc: Han-Wen Nienhuys <hanwen@google.com>
      Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ae35c325
  8. 11 6月, 2019 1 次提交
  9. 26 5月, 2019 3 次提交
  10. 04 5月, 2019 1 次提交
  11. 13 2月, 2019 3 次提交
  12. 20 12月, 2018 1 次提交
  13. 21 11月, 2018 7 次提交
    • M
      fuse: fix possibly missed wake-up after abort · 18cd6106
      Miklos Szeredi 提交于
      commit 2d84a2d19b6150c6dbac1e6ebad9c82e4c123772 upstream.
      
      In current fuse_drop_waiting() implementation it's possible that
      fuse_wait_aborted() will not be woken up in the unlikely case that
      fuse_abort_conn() + fuse_wait_aborted() runs in between checking
      fc->connected and calling atomic_dec(&fc->num_waiting).
      
      Do the atomic_dec_and_test() unconditionally, which also provides the
      necessary barrier against reordering with the fc->connected check.
      
      The explicit smp_mb() in fuse_wait_aborted() is not actually needed, since
      the spin_unlock() in fuse_abort_conn() provides the necessary RELEASE
      barrier after resetting fc->connected.  However, this is not a performance
      sensitive path, and adding the explicit barrier makes it easier to
      document.
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: b8f95e5d ("fuse: umount should wait for all requests")
      Cc: <stable@vger.kernel.org> #v4.19
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18cd6106
    • M
      fuse: fix leaked notify reply · 280da476
      Miklos Szeredi 提交于
      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: 2d45ba38 ("fuse: add retrieve request")
      Fixes: b8f95e5d ("fuse: umount should wait for all requests")
      Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c37b@syzkaller.appspotmail.com
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org> #v2.6.36
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      280da476
    • L
      fuse: fix use-after-free in fuse_direct_IO() · c0f52986
      Lukas Czerner 提交于
      commit ebacb81273599555a7a19f7754a1451206a5fc4f upstream.
      
      In async IO blocking case the additional reference to the io is taken for
      it to survive fuse_aio_complete(). In non blocking case this additional
      reference is not needed, however we still reference io to figure out
      whether to wait for completion or not. This is wrong and will lead to
      use-after-free. Fix it by storing blocking information in separate
      variable.
      
      This was spotted by KASAN when running generic/208 fstest.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Reported-by: NZorro Lang <zlang@redhat.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 744742d6 ("fuse: Add reference counting for fuse_io_priv")
      Cc: <stable@vger.kernel.org> # v4.6
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0f52986
    • M
      fuse: set FR_SENT while locked · c1ef6c98
      Miklos Szeredi 提交于
      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: NMiklos Szeredi <mszeredi@redhat.com>
      Reported-by: syzbot+ef054c4d3f64cd7f7cec@syzkaller.appspotmai
      Fixes: 46c34a34 ("fuse: no fc->lock for pqueue parts")
      Cc: <stable@vger.kernel.org> # v4.2
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1ef6c98
    • M
      fuse: fix blocked_waitq wakeup · 1ed087a7
      Miklos Szeredi 提交于
      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: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 3c18ef81 ("fuse: optimize wake_up")
      Cc: <stable@vger.kernel.org> # v3.10
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ed087a7
    • K
      fuse: Fix use-after-free in fuse_dev_do_write() · 569fda5c
      Kirill Tkhai 提交于
      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: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 46c34a34 ("fuse: no fc->lock for pqueue parts")
      Cc: <stable@vger.kernel.org> # v4.2
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      569fda5c
    • K
      fuse: Fix use-after-free in fuse_dev_do_read() · e8e17b1b
      Kirill Tkhai 提交于
      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: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 46c34a34 ("fuse: no fc->lock for pqueue parts")
      Cc: <stable@vger.kernel.org> # v4.2
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8e17b1b
  14. 02 8月, 2018 1 次提交
    • A
      kill d_instantiate_no_diralias() · c971e6a0
      Al Viro 提交于
      The only user is fuse_create_new_entry(), and there it's used to
      mitigate the same mkdir/open-by-handle race as in nfs_mkdir().
      The same solution applies - unhash the mkdir argument, then
      call d_splice_alias() and if that returns a reference to preexisting
      alias, dput() and report success.  ->mkdir() argument left unhashed
      negative with the preexisting alias moved in the right place is just
      fine from the ->mkdir() callers point of view.
      
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c971e6a0
  15. 26 7月, 2018 12 次提交
  16. 21 7月, 2018 1 次提交