linux-kernel - Forwarded: [PATCH] jfs: fix directory tree corruption in dtSplitRoot()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <69350ed8.a70a0220.38f243.0045.GAE@google.com>
Date: Sat, 06 Dec 2025 21:21:28 -0800
From: syzbot <syzbot+a099d674daa27a9272db@...kaller.appspotmail.com>
To: linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Forwarded: [PATCH] jfs: fix directory tree corruption in dtSplitRoot()

For archival purposes, forwarding an incoming command email to
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com.

***

Subject: [PATCH] jfs: fix directory tree corruption in dtSplitRoot()
Author: kartikey406@...il.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When inserting directory entries with long filenames that trigger tree
splits, the kernel crashes with "BUG at fs/jfs/jfs_dtree.c:1942" on the
assertion ASSERT(dtlck->index == 0).

The issue occurs due to improper lock reuse in txLock(). When a
transaction lock is reused (either from the same transaction or
transferred from an anonymous transaction), the dtlck->index field is
not reset, retaining its stale value from previous operations.

dtSplitRoot() expects dtlck->index to be 0 when creating a new root
node, as it needs to log directory entries starting from position 0. A
non-zero index causes entries to be written at incorrect positions,
corrupting the new root node's structure.

Lock allocation paths in txLock():
1. allocateLock path: Correctly initializes linelock->index = 0
2. Lock reuse paths: Jump to grantLock, skipping initialization

This leaves reused locks with stale index values (e.g., index=3 from
a previous operation where 3 entries were logged), causing the
assertion to fail.

Example sequence showing the bug:
- First file creation: fresh lock, index=0 -> success
- Second file creation: reused lock, index=3 -> assertion fails

Fix by unconditionally resetting dtlck->index to 0 in the grantLock
path for all DTREE lock types. This ensures clean state regardless of
whether the lock is freshly allocated or reused, preventing the stale
index from corrupting directory tree operations.

Reproducer triggers the issue with a corrupted JFS filesystem image
followed by multiple file creations with long names (~250 characters)
that force directory tree splits.

Reported-by: syzbot+a099d674daa27a9272db@...kaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a099d674daa27a9272db
Tested-by: Deepanshu Kartikey <kartikey406@...il.com>
Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>
---
 fs/jfs/jfs_txnmgr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index c16578af3a77..0bb8cf6eb1c0 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -811,6 +811,10 @@ struct tlock *txLock(tid_t tid, struct inode *ip, struct metapage * mp,
 	 * update tlock vector
 	 */
       grantLock:
+	if ((type & tlckDTREE) && (type & tlckNEW)) {
+		struct dt_lock *dtlck = (struct dt_lock *) &tlck->lock;
+		dtlck->index = 0;
+    	}
 	tlck->type |= type;

 	return tlck;
-- 
2.43.0