From nobody Fri Dec 19 11:50:00 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 7EDA62DCF45 for ; Sun, 7 Dec 2025 05:21:29 +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=1765084891; cv=none; b=XbZerHxFoWJiphFCo4EorDkjmWhQavU6p3dtadrx5q9VLcQy2GfGOHH7ExLyI4jiiCmBdS/bjYWyS57Fr5KR/jtmmO7aG5cx+te4aF9wjxovyLnU+diXf/G+8KrNmFSc9zwqksVxLOkNpLojW/fDt34DtgofRCj/iW8IS+F+cqE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765084891; c=relaxed/simple; bh=ZyH4ozCA3TUk7BcCFm+MDuLAiie4+Hu6MU1WzHoPwsY=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=nLw7Rpr6o0k4fA8CGUXiHYPf4do9Fgmj9QbRfp+rcsIbvWJizlosULsRl2qvcKWQblhlDI1L1SaDLB20OS4mMCoHa0UE88ertdasJHT479y8SqzsFOclZmGZYV+2I2yxuI8pVWqvSAoylwf7TGnMpSOW0bzYd7j+io01REgqwXI= 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-6579875eaa2so5152334eaf.3 for ; Sat, 06 Dec 2025 21:21:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765084888; x=1765689688; 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=9sTLk7HAkgK61yO/OAzUEiJX7TusV5Vx/fILiAjHikY=; b=WP3AsSKXjFFTNc9gDw7gIqQjl6GjJan9Aeo6IoK12JpfqXO+pqcX0/y7ejE9xXwD+d 6TlE2jl7sE0EXSMKHtKNmnA+SoDCePyRwBmGaazh/OGxblhrLI0VBT3vMBPjhvmcrjgZ p9EnAGijeEpr6CkTL30AENb4+uzHw9E3g9WSDlDbM0YtsUiBFFlcg5BePYComfzUVjO9 Lwz4sezaQjm78J697r7Aldly0sIGZikVpk2R70Sz+SNr6fVFCxfm2sf9TVKuu+Uf8vSB oTgEApsPLNfr6bTgYGIN1o4A7IyyFtXoo4fAoGN0g0Veqj5M1rRcqSE/bbXi3donbwVC Ix+Q== X-Gm-Message-State: AOJu0YzdNXjs0hW9y/Fu9gnEfJNix0Lw5/Sj09AgvrxS1kEGhG1zT8zV kKApdhAoIDHFIntVXzpEnrAhXULWrrkSkBR8YmNoQUVztRBFC1PiG8E6eQ67wlof3mqi+qRxXB9 gMBXN9nW9m8+HhW6opBa0Z+cBtbYE2lKlVe6mibmM3CMdfEiNshmflieiklA= X-Google-Smtp-Source: AGHT+IHtm93tmyHc8cxMr5F/X4dIfDmkVlHmkGhFEh/uzX0DHoYbI/7eMkZFMw/zndqPIYKteBtKq/TbuXWquRUEiHwbhMWe/Bj8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a4a:e914:0:b0:659:9a49:8fc4 with SMTP id 006d021491bc7-6599a973638mr1855901eaf.61.1765084888735; Sat, 06 Dec 2025 21:21:28 -0800 (PST) Date: Sat, 06 Dec 2025 21:21:28 -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: <69350ed8.a70a0220.38f243.0045.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 Tested-by: Deepanshu Kartikey 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..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, stru= ct metapage * mp, * update tlock vector */ grantLock: + if ((type & tlckDTREE) && (type & tlckNEW)) { + 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