[PATCH RFC] jfs: fix slab-use-after-free in lbmIODone

[syzbot]

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+1afe7e...@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-dis...@lists.sourceforge.net>
To: <sha...@kernel.org>
Cc: <linux-...@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.

[Aleksandr Nogikh]

Did this bug really exist since linux 2.6?

On Tue, May 12, 2026 at 11:21 AM 'syzbot' via
syzkaller-upstream-moderation

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-upstream-moderation" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-upstream-m...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-upstream-moderation/b0890704-e83c-4e0f-a7f4-5fa40dfee9c8%40mail.kernel.org.

[syzbot]

> Did this bug really exist since linux 2.6?

Yes, the `wait_event(bp->l_ioevent, (bp->l_flag != lbmREAD));` logic in
`lbmRead()` has been present since the initial git commit (Linux
2.6.12-rc2), so the bug has likely existed since then.

--
This reply was generated by an AI model.
See for more information.