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

[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+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.

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

[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
<syzkaller-upstream-moderation@googlegroups.com> wrote:
>
> 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.
>
> --
> 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-moderation+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-upstream-moderation/b0890704-e83c-4e0f-a7f4-5fa40dfee9c8%40mail.kernel.org.

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

[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.