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

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

[syzbot]

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@kernel.org
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 22cad8bc1d36 ("jfs: fix array-index-out-of-bounds in dbFindLeaf")
Reported-by: syzbot+1afe7ef2d0062e19eeb3@syzkaller.appspotmail.com
To: <jfs-discussion@lists.sourceforge.net>
To: "Dave Kleikamp" <shaggy@kernel.org>
To: "Manas Ghandat" <ghandatmanas@gmail.com>
Cc: <linux-kernel@vger.kernel.org>
Cc: <stable@vger.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

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

[Dmitry Vyukov]

On Wed, 4 Feb 2026 at 10:23, syzbot <syzbot@kernel.org> wrote:
>
> 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@kernel.org
> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
> Fixes: 22cad8bc1d36 ("jfs: fix array-index-out-of-bounds in dbFindLeaf")
> Reported-by: syzbot+1afe7ef2d0062e19eeb3@syzkaller.appspotmail.com
> To: <jfs-discussion@lists.sourceforge.net>
> To: "Dave Kleikamp" <shaggy@kernel.org>
> To: "Manas Ghandat" <ghandatmanas@gmail.com>
> Cc: <linux-kernel@vger.kernel.org>
> Cc: <stable@vger.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

Hello jfs maintainers,

Is this patch on anybody radaras? Please merge the fix.
Or should JFS patches now be sent to a generic FS tree for merging?

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

[Dave Kleikamp]

On 2/23/26 8:36AM, Dmitry Vyukov wrote:
> On Wed, 4 Feb 2026 at 10:23, syzbot <syzbot@kernel.org> wrote:
>>
>> 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@kernel.org
>> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
>> Fixes: 22cad8bc1d36 ("jfs: fix array-index-out-of-bounds in dbFindLeaf")
>> Reported-by: syzbot+1afe7ef2d0062e19eeb3@syzkaller.appspotmail.com
>> To: <jfs-discussion@lists.sourceforge.net>
>> To: "Dave Kleikamp" <shaggy@kernel.org>
>> To: "Manas Ghandat" <ghandatmanas@gmail.com>
>> Cc: <linux-kernel@vger.kernel.org>
>> Cc: <stable@vger.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
> 
> Hello jfs maintainers,
> 
> Is this patch on anybody radaras? Please merge the fix.
> Or should JFS patches now be sent to a generic FS tree for merging?

I'm way behind on JFS maintenance, but working to catch up. My problem 
with this patch is that the author is a bot. I want it to be from a real 
person, as well as any s-o-b's. Otherwise the patch looks good.

Shaggy