From: "syzbot" <syzbot@kernel.org>
To: syzkaller-upstream-moderation@googlegroups.com
Cc: syzbot@lists.linux.dev
Subject: [PATCH RFC] jfs: fix slab-use-after-free in lbmIODone
Date: Tue, 12 May 2026 09:20:57 +0000 (UTC) [thread overview]
Message-ID: <b0890704-e83c-4e0f-a7f4-5fa40dfee9c8@mail.kernel.org> (raw)
jfs: fix slab-use-after-free in lbmIODone
A KASAN slab-use-after-free was reported in lbmIODone(). The root cause
is a race condition between lbmRead() and the bio completion handler
lbmIODone(). In lbmRead(), wait_event() is used to wait for the I/O
completion locklessly. When the READ bio completes, lbmIODone() clears
the lbmREAD flag and wakes up the waiter before setting the lbmDONE flag
and releasing the LCACHE_LOCK. Because wait_event() evaluates its
condition locklessly, lbmRead() can wake up and return immediately after
the wakeup, before lbmIODone() has finished its execution.
The caller of lbmRead() (e.g., lmLogShutdown()) can then reuse the same
buffer for a WRITE bio. Meanwhile, the original lbmIODone() resumes and
erroneously sets the lbmDONE flag on the reused buffer. This causes a
subsequent lbmIOWait() on the new WRITE bio to return early and free the
buffer. When the WRITE bio actually completes, lbmIODone() accesses the
freed buffer, triggering the use-after-free.
Fix this by replacing the lockless wait_event() in lbmRead() with
lbmIOWait(bp, 0). lbmIOWait() properly synchronizes with lbmIODone() by
acquiring LCACHE_LOCK before checking the condition, ensuring lbmRead()
will block until lbmIODone() has completely finished. As an added
benefit, lbmIOWait() correctly returns -EIO if the bio completes with an
error, whereas the previous implementation unconditionally returned 0.
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview
Reported-by: syzbot+1afe7ef2d0062e19eeb3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=1afe7ef2d0062e19eeb3
Link: https://syzkaller.appspot.com/ai_job?id=5deba876-6901-4e25-bb74-5f9dc95dd56a
To: <jfs-discussion@lists.sourceforge.net>
To: <shaggy@kernel.org>
Cc: <linux-kernel@vger.kernel.org>
---
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index 306165e61..cf62a8564 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -1984,9 +1984,7 @@ static int lbmRead(struct jfs_log * log, int pn, struct lbuf ** bpp)
submit_bio(bio);
}
- wait_event(bp->l_ioevent, (bp->l_flag != lbmREAD));
-
- return 0;
+ return lbmIOWait(bp, 0);
}
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
This is an AI-generated patch subject to moderation.
Reply with '#syz upstream' to send it to the mailing list.
Reply with '#syz reject' to reject it.
See for more information.
next reply other threads:[~2026-05-12 9:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 9:20 syzbot [this message]
2026-05-13 20:09 ` [PATCH RFC] jfs: fix slab-use-after-free in lbmIODone Aleksandr Nogikh
2026-05-15 10:33 ` syzbot
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=b0890704-e83c-4e0f-a7f4-5fa40dfee9c8@mail.kernel.org \
--to=syzbot@kernel.org \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-upstream-moderation@googlegroups.com \
/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.