From: Joanne Koong <joannelkoong@gmail.com>
To: miklos@szeredi.hu
Cc: fuse-devel@lists.linux.dev, bernd@bsbernd.com, ali@ddn.com,
horst@birthelmer.de, stable@vger.kernel.org
Subject: [PATCH v1 1/3] fuse: fix race between ring creation and connection abortion
Date: Thu, 14 May 2026 21:55:39 -0700 [thread overview]
Message-ID: <20260515045541.1171335-2-joannelkoong@gmail.com> (raw)
In-Reply-To: <20260515045541.1171335-1-joannelkoong@gmail.com>
This fixes this race:
- thread a: fuse_uring_cmd() gets called, passes fch->connected check
(connection abortion not yet triggered)
- thread b: abort is called, calls fuse_uring_abort(),
fuse_uring_abort() is a no-op since ring == NULL right now
- thread a: creates ring, creates queue, creates entry
which results in
- leaked ring, queue, ent
- if thread a increments queue_refs before thread b calls
fuse_chan_wait_aborted(), then fuse_chan_wait_aborted() calls
"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);"
which will hang the abort/unmount thread indefinitely in unkillable
state, as nothing will decrement queue_refs or wake stop_waitq.
Fix this by checking fch->connected under fch->lock in
fuse_uring_create() before publishing the ring via
smp_store_release(&fch->ring, ring) under the same lock scope.
Fixes: 24fe962c86f5 ("fuse: {io-uring} Handle SQEs - register commands")
Cc: <stable@vger.kernel.org>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
fs/fuse/dev_uring.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c
index e467b23e6895..cd75f61018ec 100644
--- a/fs/fuse/dev_uring.c
+++ b/fs/fuse/dev_uring.c
@@ -244,6 +244,10 @@ static struct fuse_ring *fuse_uring_create(struct fuse_chan *fch)
max_payload_size = max(max_payload_size, fch->max_pages * PAGE_SIZE);
spin_lock(&fch->lock);
+ if (!fch->connected) {
+ spin_unlock(&fch->lock);
+ goto out_err;
+ }
if (fch->ring) {
/* race, another thread created the ring in the meantime */
spin_unlock(&fch->lock);
--
2.52.0
next prev parent reply other threads:[~2026-05-15 4:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 4:55 [PATCH v1 0/3] fuse: fix io-uring abort races and cancel null deref Joanne Koong
2026-05-15 4:55 ` Joanne Koong [this message]
2026-05-15 11:57 ` [PATCH v1 1/3] fuse: fix race between ring creation and connection abortion Bernd Schubert
2026-05-15 20:49 ` Joanne Koong
2026-05-15 4:55 ` [PATCH v1 2/3] fuse: fix race between registration " Joanne Koong
2026-05-15 11:59 ` Bernd Schubert
2026-05-15 4:55 ` [PATCH v1 3/3] fuse: fix moving cancelled entry to ent_in_userspace list Joanne Koong
2026-05-15 11:10 ` Bernd Schubert
2026-05-15 21:11 ` Joanne Koong
2026-05-15 22:27 ` Bernd Schubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260515045541.1171335-2-joannelkoong@gmail.com \
--to=joannelkoong@gmail.com \
--cc=ali@ddn.com \
--cc=bernd@bsbernd.com \
--cc=fuse-devel@lists.linux.dev \
--cc=horst@birthelmer.de \
--cc=miklos@szeredi.hu \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.