]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
fuse: check connected before queueing on fpq->io
authorMiklos Szeredi <mszeredi@redhat.com>
Tue, 22 Jun 2021 07:15:35 +0000 (09:15 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 20 Jul 2021 14:15:42 +0000 (16:15 +0200)
commit1c37784a00edfb88be67b24f7e776cda9eb803fd
tree0ec581ee3530f81f9fea27ee27a849922d52f94a
parent77c94b2a1deea733e2796a2da7b637c1afd0cdb8
fuse: check connected before queueing on fpq->io

commit 80ef08670d4c28a06a3de954bd350368780bcfef upstream.

A request could end up on the fpq->io list after fuse_abort_conn() has
reset fpq->connected and aborted requests on that list:

Thread-1   Thread-2
========   ========
->fuse_simple_request()           ->shutdown
  ->__fuse_request_send()
    ->queue_request() ->fuse_abort_conn()
->fuse_dev_do_read()                ->acquire(fpq->lock)
  ->wait_for(fpq->lock)    ->set err to all req's in fpq->io
  ->release(fpq->lock)
  ->acquire(fpq->lock)
  ->add req to fpq->io

After the userspace copy is done the request will be ended, but
req->out.h.error will remain uninitialized.  Also the copy might block
despite being already aborted.

Fix both issues by not allowing the request to be queued on the fpq->io
list after fuse_abort_conn() has processed this list.

Reported-by: Pradeep P V K <pragalla@codeaurora.org>
Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
Cc: <stable@vger.kernel.org> # v4.2
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/fuse/dev.c