From: Tristan Madani <tristmd@gmail.com>
To: Dave Kleikamp <shaggy@kernel.org>
Cc: jfs-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
syzbot+c244f4a09ca85dd2ebc1@syzkaller.appspotmail.com,
syzbot+885a4f3281b8d99c48d8@syzkaller.appspotmail.com,
stable@vger.kernel.org,
Tristan Madani <tristan@talencesecurity.com>
Subject: [PATCH v2 1/2] jfs: drain lazy commit queue during unmount to prevent use-after-free
Date: Tue, 5 May 2026 12:33:29 +0000 [thread overview]
Message-ID: <20260505123330.2822833-2-tristmd@gmail.com> (raw)
In-Reply-To: <20260505123330.2822833-1-tristmd@gmail.com>
From: Tristan Madani <tristan@talencesecurity.com>
The jfsCommit kernel thread processes committed transactions from
TxAnchor.unlock_queue via jfs_lazycommit(). During filesystem
unmount, jfs_umount() calls jfs_flush_journal(log, 2) which waits
for the log commit queue (log->cqueue) to drain. However, after
log I/O completes, lazy transactions are moved to
TxAnchor.unlock_queue for asynchronous processing by jfsCommit.
If jfs_umount() proceeds to free the jfs_log (via lmLogClose) or
jfs_sb_info (via kfree in jfs_put_super) while entries referencing
this superblock remain on unlock_queue, the jfsCommit thread will
access freed memory when it later processes these entries:
- jfs_lazycommit reads sbi->commit_state (UAF of jfs_sb_info)
- txLazyCommit accesses JFS_SBI(tblk->sb)->log and takes
log->gclock (UAF of jfs_log)
Add txLazyDrain() which waits for all entries in
TxAnchor.unlock_queue belonging to the unmounting superblock to be
processed, and also waits for any in-flight txLazyCommit
(IN_LAZYCOMMIT) for this superblock to complete. Call it from both
jfs_umount() and jfs_umount_rw() after jfs_flush_journal().
Reported-by: syzbot+c244f4a09ca85dd2ebc1@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c244f4a09ca85dd2ebc1
Tested-by: syzbot+c244f4a09ca85dd2ebc1@syzkaller.appspotmail.com
Reported-by: syzbot+885a4f3281b8d99c48d8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=885a4f3281b8d99c48d8
Tested-by: syzbot+885a4f3281b8d99c48d8@syzkaller.appspotmail.com
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_txnmgr.c | 35 +++++++++++++++++++++++++++++++++++
fs/jfs/jfs_txnmgr.h | 1 +
fs/jfs/jfs_umount.c | 8 ++++++++
3 files changed, 44 insertions(+)
diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index 083dbbb0c3268..67a9908b5a4d9 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -2791,6 +2791,41 @@ void txLazyUnlock(struct tblock * tblk)
LAZY_UNLOCK(flags);
}
+
+/*
+ * txLazyDrain
+ *
+ * Wait for all pending lazy commit entries for this superblock
+ * to be processed by the jfsCommit thread. Must be called
+ * before freeing per-filesystem structures during unmount.
+ */
+void txLazyDrain(struct super_block *sb)
+{
+ struct jfs_sb_info *sbi = JFS_SBI(sb);
+ struct tblock *tblk;
+ unsigned long flags;
+ bool found;
+
+ do {
+ found = false;
+ LAZY_LOCK(flags);
+ list_for_each_entry(tblk, &TxAnchor.unlock_queue, cqueue) {
+ if (tblk->sb == sb) {
+ found = true;
+ break;
+ }
+ }
+ if (!found && (sbi->commit_state & IN_LAZYCOMMIT))
+ found = true;
+ LAZY_UNLOCK(flags);
+
+ if (found) {
+ wake_up(&jfs_commit_thread_wait);
+ schedule_timeout_uninterruptible(1);
+ }
+ } while (found);
+}
+
static void LogSyncRelease(struct metapage * mp)
{
struct jfs_log *log = mp->log;
diff --git a/fs/jfs/jfs_txnmgr.h b/fs/jfs/jfs_txnmgr.h
index ba71eb5ced567..80ce468eadde0 100644
--- a/fs/jfs/jfs_txnmgr.h
+++ b/fs/jfs/jfs_txnmgr.h
@@ -291,6 +291,7 @@ extern void txFreelock(struct inode *);
extern int lmLog(struct jfs_log *, struct tblock *, struct lrd *,
struct tlock *);
extern void txQuiesce(struct super_block *);
+extern void txLazyDrain(struct super_block *sb);
extern void txResume(struct super_block *);
extern void txLazyUnlock(struct tblock *);
extern int jfs_lazycommit(void *);
diff --git a/fs/jfs/jfs_umount.c b/fs/jfs/jfs_umount.c
index 18569f1eaabdb..657707361be2a 100644
--- a/fs/jfs/jfs_umount.c
+++ b/fs/jfs/jfs_umount.c
@@ -58,6 +58,13 @@ int jfs_umount(struct super_block *sb)
*/
jfs_flush_journal(log, 2);
+ /*
+ * Drain any pending lazy commit entries for this filesystem so
+ * the jfsCommit thread does not access freed structures.
+ */
+ if (log)
+ txLazyDrain(sb);
+
/*
* Hold log lock so write_special_inodes (lmLogSync) cannot see
* this sbi with a NULL inode pointer while iterating log->sb_list.
@@ -142,6 +149,7 @@ int jfs_umount_rw(struct super_block *sb)
* remove file system from log active file system list.
*/
jfs_flush_journal(log, 2);
+ txLazyDrain(sb);
/*
* Make sure all metadata makes it to disk
--
2.47.3
next prev parent reply other threads:[~2026-05-05 12:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 11:02 [PATCH] jfs: drain lazy commit queue during unmount to prevent use-after-free Tristan Madani
2026-05-05 12:33 ` [PATCH v2 0/2] jfs: fix use-after-free races during unmount Tristan Madani
2026-05-05 12:33 ` Tristan Madani [this message]
2026-05-05 12:33 ` [PATCH v2 2/2] jfs: wait for in-flight log I/O before freeing lbufs in lbmLogShutdown Tristan Madani
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=20260505123330.2822833-2-tristmd@gmail.com \
--to=tristmd@gmail.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=shaggy@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+885a4f3281b8d99c48d8@syzkaller.appspotmail.com \
--cc=syzbot+c244f4a09ca85dd2ebc1@syzkaller.appspotmail.com \
--cc=tristan@talencesecurity.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox