From nobody Fri Dec 19 11:48:15 2025 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (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 0398F223710 for ; Sun, 7 Dec 2025 06:58:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765090697; cv=none; b=QnK9oKSRFJxgoc4Qd7NSms+wIk3eHYCsWZSiLEqb2NY9KiX80+SLo2d4CtjgJJjdZbNczIUapHf+NJ+gZCKpHdVfXNVxDizdD7qVwF3rozs8aDs6cNHnGBmeiMvwE6I6lm9AXLM/MsTbcox9MGb6jmNIgCDEU0BQqu6EGKW4qpw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765090697; c=relaxed/simple; bh=4v+TNlkniu4wxLLqhlhd5FkPjeRADQ1IuH0LxWYwY2A=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=beHKIjH4oogMGXL9l6uNbRQ2C2wAfLqiq32gIYBoODzio71Zmr6cdp6u3QEVqJVF7qUZ8cx+t866TsIR1bUwS9wTPnAKvMcz5WsNjub0nzX+QhwiXFjL4O86XAR3BbEtimk21H+rnFClUISbXVpS/8V9fRKRlJXPv1CXz9gaZ+Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GXF55MPi; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GXF55MPi" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-349b711d106so460580a91.1 for ; Sat, 06 Dec 2025 22:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765090695; x=1765695495; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=e31pJQGgbdFp8qgVDnCkMYCpVAZCje46ZRMyi85fPTA=; b=GXF55MPiCFKfsiIEswM79VWdI9C+DAuseu+rYo+FcwQsREN3NMY8Q9r8iHx5fCOuve 10Ulxnch1xPWR5TBZoXslbRlVhiKctFryPKCeQXYTuDZwduv6DcS6X7rR+n2L6M3PZx2 /tzvKLoujYKff3W6jWZiQMwYxNC5fLvGyUDD3/6UshtN4wefHqXB/zp5HX5S5akpDUc3 XB9TzSjf9mJiCM/Glu0XQvRs4ioSVO53lMwXniW7/3KdxXNUnu1HFwQfqNokj/Xve/ag vaeayPscfVJ0dFFuDsG2fT3CxaxLYgVKx9xUpZ3d08TYnT1Ul+CXcqjUg2mWwTi0UCM5 j4iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765090695; x=1765695495; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e31pJQGgbdFp8qgVDnCkMYCpVAZCje46ZRMyi85fPTA=; b=RhCJPuEJWmDyUfkaJLpBY+CK9BN3uPyyJjUpnoKSmhCeVIjRc+P9vZiVQFae7zhjEV aCrGDrGbIKgzD2KLUkylakBH/kUWVaXdPAH6SzWOa3UrH6a4WwVUpumkH+lF9kMsgog9 cqw0ERPLB9av60zHy6PDgcFBvBOU3xehEOP+dhAqG7GlymyjpIWVxhA4LTD3VE8OXaCr cYfuoS14azeEb8BKHF3HTVAAxqImn6bnnIjd/ZygUJjvWHyKo3vUTTUGWtyhnDwzHTIa lG/QREpahmPL33BQUUlKhMPPjrV93UDqxR+CmvLYJKz5L+XMyYHjGDrVf9aUjLak2c0d +qkA== X-Forwarded-Encrypted: i=1; AJvYcCXo4/0nhPfP5bIvQ6PBucX/9JSko3iXlcAfbHyTDH9u+otw38J+FzjBkTUMpdZnhbet7DekImASmptODPc=@vger.kernel.org X-Gm-Message-State: AOJu0YzgJBDzbHqbhzSq/h9dVa3virbd8NYKt+iL9kk8gMbXoBM8Ne4K 3sC3XwLSh1NyIAfIQ6hYPCgjgxJ6wZf/HKj5vPCLgrY2/rnTmQ6vPtbIU//6K24o X-Gm-Gg: ASbGnctINnIgIk2m0EVOHBSQzhjiJAPaCTzF/vrSq6YnJzt/+0pg7Xg4g7QoPeP005B s00RSc076/VWgSc/zvhigr8bgW26B3a0KLiGO1lKlOYgC7UFYNKR64aYqhuAJdWsG44VKyQqR2g 8Pdv5n+DaURC3UAUK1iMeqaDM3kdi01/VsFxU1ByvjKRni7Olrsg3750vPZDmyqpJ2Om/8w1n7B ly8+CTP08yHljBcH3G2r0Ixu6zUy4EZRjRnDPy5Yf4AGtBPDjGD0yffCpOMcOUFt7/V40N/GJOF b5zJ3GBTB4HzWOa6EWNKVzIyhWKhv0lNdiEdbxCtaJ6cCqqFm+a4P0b2tMlchtOVlgFjmhoQb0G viUA27o0uZs1FPH5YhJ3RdbWufvQbQQ8ps/oUFJr0u2xu7A4mjmcMVlm8PYQln1NBvSxH1QevJm av7ZwdLXYVaFn4dWTJL8kjod8X4tkLR1mPOkRJvGQP+OIVdyQa4w9Ny6ociSBXcDEkVmSQ7lDhc h1dMQ== X-Google-Smtp-Source: AGHT+IHddt5/Uga5pkbbG71Gt44w7xeJXbFnimz19khQFtfhIOnypOcomPSiQh6tyrOU1UZiD3CZKg== X-Received: by 2002:a17:90b:3ec1:b0:340:6f07:fefa with SMTP id 98e67ed59e1d1-349a268034amr3677106a91.20.1765090695209; Sat, 06 Dec 2025 22:58:15 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:6893:b3d4:beeb:8a65]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3494ea63e87sm8633964a91.12.2025.12.06.22.58.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Dec 2025 22:58:14 -0800 (PST) From: Deepanshu Kartikey To: shaggy@kernel.org, brauner@kernel.org Cc: mjguzik@gmail.com, jfs-discussion@lists.sourceforge.net, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+a099d674daa27a9272db@syzkaller.appspotmail.com Subject: [PATCH] jfs: fix directory tree corruption in dtSplitRoot() Date: Sun, 7 Dec 2025 12:28:01 +0530 Message-ID: <20251207065801.2611800-1-kartikey406@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 =3D=3D 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=3D3 from a previous operation instead of the expected index=3D0. Fix by resetting dtlck->index to 0 at the grantLock label, but only for operations with the tlckNEW flag set. This ensures new pages start with clean state while preserving accumulated changes on existing pages. 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 | 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, stru= ct 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 =3D (struct dt_lock *)&tlck->lock; + + dtlck->index =3D 0; + } tlck->type |=3D type; =20 return tlck; --=20 2.43.0