linux-kernel - [PATCH] jfs: fix array-index-out-of-bounds in dbFindLeaf

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>] [day] [month] [year] [list]

Message-ID: <20260204092230.2540042-1-syzbot@kernel.org>
Date: Wed,  4 Feb 2026 10:22:30 +0100
From: syzbot <syzbot@...nel.org>
To: jfs-discussion@...ts.sourceforge.net,
	shaggy@...nel.org,
	ghandatmanas@...il.com
Cc: syzbot <syzbot@...nel.org>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	syzbot+1afe7ef2d0062e19eeb3@...kaller.appspotmail.com,
	linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: [PATCH] jfs: fix array-index-out-of-bounds in dbFindLeaf

UBSAN reported an array-index-out-of-bounds issue in dbFindLeaf:

  index 1365 is out of range for type 's8[1365]' (aka 'signed char[1365]')
  CPU: 0 UID: 0 PID: 6287 Comm: syz-executor268 Not tainted ...
  Call Trace:
   ...
   __ubsan_handle_out_of_bounds+0x115/0x140 lib/ubsan.c:455
   dbFindLeaf+0x308/0x520 fs/jfs/jfs_dmap.c:2976
   dbFindCtl+0x267/0x520 fs/jfs/jfs_dmap.c:1717
   ...

The issue is caused by an off-by-one error in the bounds check within
dbFindLeaf. The function traverses the dmap tree to find free blocks.
It uses a loop to iterate through the levels of the tree, calculating
the index `x + n` to access the `tp->dmt_stree` array. The variable
`max_size` represents the size of this array (CTLTREESIZE (1365) for
dmapctl or TREESIZE (341) for dmaptree).

The bounds check `if (x + n > max_size)` allows `x + n` to be equal to
`max_size`. However, since the array size is `max_size`, the valid
indices are `0` to `max_size - 1`. Accessing `tp->dmt_stree[max_size]`
results in an array-index-out-of-bounds access.

This can occur when the `dmt_height` field in the on-disk structure is
corrupted or fuzzed to be larger than the fixed height supported by the
`dmt_stree` array.

Fix this by changing the condition to `>=` to correctly reject indices
equal to or greater than the array size.

Signed-off-by: syzbot@...nel.org
Signed-off-by: Dmitry Vyukov <dvyukov@...gle.com>
Fixes: 22cad8bc1d36 ("jfs: fix array-index-out-of-bounds in dbFindLeaf")
Reported-by: syzbot+1afe7ef2d0062e19eeb3@...kaller.appspotmail.com
To: <jfs-discussion@...ts.sourceforge.net>
To: "Dave Kleikamp" <shaggy@...nel.org>
To: "Manas Ghandat" <ghandatmanas@...il.com>
Cc: <linux-kernel@...r.kernel.org>
Cc: <stable@...r.kernel.org>
---
This patch was generated by Google Gemini LLM model.
It was pre-reviewed and Signed-off-by a human, but please review carefully.

Gerrit code review with full side-by-side diffs:
https://linux-review.git.corp.google.com/c/linux/kernel/git/torvalds/linux/+/26122

Change-Id: I92f694e86518349eafa132b2ba314d8dfff6c86e
---

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index cdfa699..18a7dc5 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2971,7 +2971,7 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
 			/* sufficient free space found.  move to the next
 			 * level (or quit if this is the last level).
 			 */
-			if (x + n > max_size)
+			if (x + n >= max_size)
 				return -ENOSPC;
 			if (l2nb <= tp->dmt_stree[x + n])
 				break;

base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377