From nobody Fri Dec 19 11:50:38 2025 Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E87C71CEAB2 for ; Sun, 7 Dec 2025 04:57:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.70 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765083432; cv=none; b=UL/cnAzR10vgp5XusyW1MDor84lG0LDXPOp18rGC8zAn/NO2NKfj+9xoViDItWmJB0bW1T/NCwLKWCuMAFIt6ku5SdPRWTJYmCwMgS8hxVYTAaaCZ/oAU99FV9gJUmr+9jNMp9JGJFFc6kvgMsGt3ILs7EDx6SyLzMIXTLxWwak= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765083432; c=relaxed/simple; bh=Efzna8b7OZFxfHeJQUelDcCWzXFz8HgSWJweEX42NHQ=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=afjlHiYZB/hfh+pC6roDxIEZx7nwxphvTlBOlTYp7wzzqGzfhaD2jU6n+a95AiJIKfGGyHOjwelRdIXlO5ImK9JS5n1AuMef/hfyeXcdAaXBfsl5byPTODwA7X3e9aVJRqzmFvYz2ZUNRiavLp1Rv3YlCIulLw9ul3cKghKdomQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-65747f4376bso5275494eaf.2 for ; Sat, 06 Dec 2025 20:57:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765083430; x=1765688230; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gYucx4Jaye5Ow0PY1SlSEJFaAoVR1I7nJzkVfm31Kaw=; b=wVU84ws2MkDdtZrocaWNVb5BdajSPICXVC5F6VPZNV6ucH0anQoM9mg7WH5ctOJ+Ja P0KMG3HVCWo4b1Thkj/Hn4cC75SlSje7Rbd6pntMJEIgFXtO7TLJ0E6om4uApy6bnjwU UOBbjdVoF5p97BpSJptBpmBGq/LfoZsze4JzZLOdXynQ1VZik6YbCKQ0WWdepXDyOik8 iql06lClZnH7tgDonENc3AgO3e1+Ll/w0g11JpVg4BP4k8awMMVx7afwwKjXJMoEEjn4 IobwQ4d/15CnoVlv47/edB1sQ2dR6g9uTfyLiFRfH4afZgX1Le++BraxtRO5jPiDWqXx lfWw== X-Gm-Message-State: AOJu0YwimpyjM9102TV/c1tzZImhWlbo3SPNdu9qwBkPzwy/cxj3m4FO 5OZ9wQD82SCOH6xzKFmI24Hu9zU5QarBkQyBeFXEOPcXMjG48LAVNvAhiKLjhRp2BD9GIBkzDD/ Yyt0MorvfgPFLgi9/tMXzY7W2Faye4qkvsd6cnbXXtrItuRUhLFz5/j/pnlM= X-Google-Smtp-Source: AGHT+IGSNDz4VhYl6oM2Fo6oIZakE1a/8Hs+2+o+Qrzb5X5p2DqJVyFZVSNHsl13Sn/iZuZsODML3GsNThCzp7X56Y3L1Qztten2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:f07:b0:659:9a49:8ecd with SMTP id 006d021491bc7-6599a983334mr1466724eaf.81.1765083430064; Sat, 06 Dec 2025 20:57:10 -0800 (PST) Date: Sat, 06 Dec 2025 20:57:10 -0800 In-Reply-To: <6933eb82.a70a0220.38f243.001a.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69350926.a70a0220.38f243.0042.GAE@google.com> Subject: Forwarded: [PATCH] jfs: fix directory tree corruption in dtSplitRoot() From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] jfs: fix directory tree corruption in dtSplitRoot() Author: kartikey406@gmail.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 =3D=3D 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 =3D 0 2. Lock reuse paths: Jump to grantLock, skipping initialization This leaves reused locks with stale index values (e.g., index=3D3 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=3D0 -> success - Second file creation: reused lock, index=3D3 -> 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@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Da099d674daa27a9272db Signed-off-by: Deepanshu Kartikey --- 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..2c0678b03f66 100644 --- a/fs/jfs/jfs_txnmgr.c +++ b/fs/jfs/jfs_txnmgr.c @@ -811,6 +811,11 @@ struct tlock *txLock(tid_t tid, struct inode *ip, stru= ct metapage * mp, * update tlock vector */ grantLock: + if (type & tlckDTREE) { + struct dt_lock *dtlck =3D (struct dt_lock *) &tlck->lock; + + dtlck->index =3D 0; + } tlck->type |=3D type; =20 return tlck; --=20 2.43.0