From: David Lee <david.lee@trailofbits.com>
To: miklos@szeredi.hu
Cc: David Lee <david.lee@trailofbits.com>,
Kyle Zeng <kylebot@openai.com>,
Dominik 'Disconnect3d' Czarnota
<dominik.czarnota@trailofbits.com>,
fuse-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH] fuse: wait for sync init request after abort
Date: Fri, 31 Jul 2026 12:03:52 +0000 [thread overview]
Message-ID: <20260731120353.558833-1-david.lee@trailofbits.com> (raw)
After a fatal signal interrupts synchronous FUSE_INIT,
request_wait_answer() aborts the channel and returns immediately. If the
request is in an FR_LOCKED reply-copy interval, fuse_chan_abort() leaves
it for the writer to finish. The synchronous caller can then free the
fuse_init_args that owns the reply destination while the writer is still
copying into it.
Wait for fuse_request_end() after aborting the channel. This keeps the
synchronous caller's reply storage alive until any locked copy has
finished, while preserving the fatal-signal abort behavior.
Fixes: 204aa22a686b ("fuse: abort on fatal signal during sync init")
Cc: stable@vger.kernel.org
Bug found and triaged by OpenAI Security Research and
validated by Trail of Bits.
Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
Trail of Bits has a reproducer for this bug that triggers a
KASAN use-after-free and can share if needed.
fs/fuse/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 5763a7cd3..deee1585d 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -725,6 +725,8 @@ static void request_wait_answer(struct fuse_req *req)
if (req->args->abort_on_kill) {
fuse_chan_abort(fch, false);
+ wait_event(req->waitq,
+ test_bit(FR_FINISHED, &req->flags));
return;
}
--
2.53.0
next reply other threads:[~2026-07-31 12:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 12:03 David Lee [this message]
2026-08-02 8:36 ` [PATCH] fuse: wait for sync init request after abort Sven Eckelmann
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=20260731120353.558833-1-david.lee@trailofbits.com \
--to=david.lee@trailofbits.com \
--cc=dominik.czarnota@trailofbits.com \
--cc=fuse-devel@lists.linux.dev \
--cc=kylebot@openai.com \
--cc=linux-kernel@vger.kernel.org \
--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.