linux-kernel - Re: [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] [day] [month] [year] [list]

Message-ID: <CADhLXY7Za9F5+-h35+7QFJq23LUZyYxEfMhq2NTH1DfiDm4S+A@mail.gmail.com>
Date: Sun, 7 Dec 2025 12:25:26 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: shaggy@...nel.org, brauner@...nel.org
Cc: mjguzik@...il.com, jfs-discussion@...ts.sourceforge.net, 
	linux-kernel@...r.kernel.org, 
	syzbot+a099d674daa27a9272db@...kaller.appspotmail.com
Subject: Re: [PATCH] jfs: fix directory tree corruption in dtSplitRoot()

On Sun, Dec 7, 2025 at 12:21 PM Deepanshu Kartikey
<kartikey406@...il.com> wrote:
>
> When reusing transaction locks for DTREE operations, the index field
> may contain stale values from previous operations, causing assertion
> failures in dtSplitRoot():
>
>   ASSERT(dtlck->index == 0)
>
> This results in kernel crashes like:
>
>   kernel BUG at fs/jfs/jfs_dtree.c:1942!
>   Call Trace:
>    dtSplitRoot+0x1694/0x16c0 fs/jfs/jfs_dtree.c:1942
>    dtSplitUp fs/jfs/jfs_dtree.c:1244 [inline]
>    dtInsert+0x2525/0x5f40 fs/jfs/jfs_dtree.c:871
>    jfs_create+0x6c8/0xa80 fs/jfs/namei.c:137
>
> The bug occurs because txLock() has multiple code paths for lock
> acquisition:
>
> 1. Fresh allocation (allocateLock) - correctly initializes index to 0
> 2. Lock reuse (same transaction) - skips initialization
> 3. Anonymous lock acquisition - skips initialization
>
> Paths 2 and 3 jump directly to the grantLock label, bypassing the
> index initialization. When dtSplitRoot() is called multiple times
> within a batched transaction (which JFS uses for performance), it may
> receive a reused lock with index=3 from a previous operation instead
> of the expected index=0.
>
> Example sequence:
>   Transaction tid=1:
>     - First dtSplitRoot: gets fresh lock, index=0 ✓
>     - Modifies entries, index becomes 3
>     - Lock returned to pool but not freed
>
>   Transaction tid=1 (continues):
>     - Second dtSplitRoot: reuses same lock
>     - index still = 3 (stale value) ✗
>     - ASSERT(index == 0) fails → crash
>
> Fix by resetting dtlck->index to 0 at the grantLock label, but only
> for operations with the tlckNEW flag set. This ensures:
>
> - New pages (like dtSplitRoot) start with clean state (index=0)
> - Existing pages preserve accumulated changes within a transaction
> - No performance impact (only affects new page operations)
>
> The tlckNEW flag is used by dtSplitRoot() when creating a new root
> page, making this fix targeted to the exact scenario that requires
> index=0.
>
> Reported-by: syzbot+a099d674daa27a9272db@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=a099d674daa27a9272db
> Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>
> ---
>  fs/jfs/jfs_txnmgr.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
> index c16578af3a77..5ce2fc17d967 100644
> --- a/fs/jfs/jfs_txnmgr.c
> +++ b/fs/jfs/jfs_txnmgr.c
> @@ -811,6 +811,17 @@ struct tlock *txLock(tid_t tid, struct inode *ip, struct metapage * mp,
>          * update tlock vector
>          */
>        grantLock:
> +       /*
> +        * Reset index for new DTREE locks to ensure clean state.
> +        * When locks are reused, index may contain stale values from
> +        * previous operations. Operations like dtSplitRoot() expect
> +        * index to be 0 when creating new pages (tlckNEW flag).
> +        */
> +       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
>

Please disregard this patch. As,  it contains special characters. I
will be resending the patch again

Thanks

Deepanshu