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

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

[Manas Ghandat]

Currently while searching for dmtree_t for sufficient free blocks there
is an array out of bounds while getting element in tp->dm_stree. Added
the required bound check.

Ps: After I added the check I am getting the following log

[   22.661748][ T4425] ERROR: (device loop0): dbAllocAny: unable to allocate blocks
[   22.661748][ T4425]
[   22.665536][ T4425] ERROR: (device loop0): remounting filesystem as read-only
[   22.667856][ T4425] jfs_mkdir: dtInsert returned -EIO
[   22.669750][ T4425] ERROR: (device loop0): txAbort:

I was wondering if these checks are significant of not?

Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com>
Reported-by: syzbot+aea1ad91e854d0a83e04@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=aea1ad91e854d0a83e04
---
 fs/jfs/jfs_dmap.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index a14a0f18a4c4..5af17b2287be 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2948,6 +2948,10 @@ static int dbFindLeaf(dmtree_t * tp, int l2nb, int *leafidx)
 			/* sufficient free space found.  move to the next
 			 * level (or quit if this is the last level).
 			 */
+
+			if (x + n > TREESIZE)
+				return -ENOSPC;
+
 			if (l2nb <= tp->dmt_stree[x + n])
 				break;
 		}
-- 
2.37.2

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

[Dave Kleikamp]

On 8/29/23 11:52AM, Manas Ghandat wrote:
> Currently while searching for dmtree_t for sufficient free blocks there
> is an array out of bounds while getting element in tp->dm_stree. Added
> the required bound check.
> 
> Ps: After I added the check I am getting the following log
> 
> [   22.661748][ T4425] ERROR: (device loop0): dbAllocAny: unable to allocate blocks
> [   22.661748][ T4425]
> [   22.665536][ T4425] ERROR: (device loop0): remounting filesystem as read-only
> [   22.667856][ T4425] jfs_mkdir: dtInsert returned -EIO
> [   22.669750][ T4425] ERROR: (device loop0): txAbort:
> 
> I was wondering if these checks are significant of not?

This won't work. dbFindLeaf() can be called from dbFindCtl() with struct 
dmapctl whose stree index can be as high as CTLTREESIZE which is larger 
than TREESIZE. A check against CTLTREESIZE might be better than nothing 
at all but won't necessarily detect an overflow. Currently, dbFindLeaf 
doesn't have anything to tell it which tree it is working on.

We could pass in the treesize as an argument to dbFindCtl() if we can't 
come up with something simpler.

Shaggy

> 
> Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com>
> Reported-by: syzbot+aea1ad91e854d0a83e04@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=aea1ad91e854d0a83e04
> ---
>   fs/jfs/jfs_dmap.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index a14a0f18a4c4..5af17b2287be 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -2948,6 +2948,10 @@ static int dbFindLeaf(dmtree_t * tp, int l2nb, int *leafidx)
>   			/* sufficient free space found.  move to the next
>   			 * level (or quit if this is the last level).
>   			 */
> +
> +			if (x + n > TREESIZE)
> +				return -ENOSPC;
> +
>   			if (l2nb <= tp->dmt_stree[x + n])
>   				break;
>   		}

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

[Manas Ghandat]

I was wondering if we could implement a get_tree_size macro wherein  we 
could find the tree size so that we can do the comparison. SInce the 
tp->dmt_stree is an array we can get its size and fix the out of bounds. 
Would this thing work?

On 30/08/23 00:08, Dave Kleikamp wrote:
> This won't work. dbFindLeaf() can be called from dbFindCtl() with 
> struct dmapctl whose stree index can be as high as CTLTREESIZE which 
> is larger than TREESIZE. A check against CTLTREESIZE might be better 
> than nothing at all but won't necessarily detect an overflow. 
> Currently, dbFindLeaf doesn't have anything to tell it which tree it 
> is working on.
>
> We could pass in the treesize as an argument to dbFindCtl() if we 
> can't come up with something simpler.
>
> Shaggy
>
>>
>> Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com>
>> Reported-by: syzbot+aea1ad91e854d0a83e04@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=aea1ad91e854d0a83e04
>> ---
>>   fs/jfs/jfs_dmap.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
>> index a14a0f18a4c4..5af17b2287be 100644
>> --- a/fs/jfs/jfs_dmap.c
>> +++ b/fs/jfs/jfs_dmap.c
>> @@ -2948,6 +2948,10 @@ static int dbFindLeaf(dmtree_t * tp, int l2nb, 
>> int *leafidx)
>>               /* sufficient free space found.  move to the next
>>                * level (or quit if this is the last level).
>>                */
>> +
>> +            if (x + n > TREESIZE)
>> +                return -ENOSPC;
>> +
>>               if (l2nb <= tp->dmt_stree[x + n])
>>                   break;
>>           }

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

[Dave Kleikamp]

On 8/31/23 10:19AM, Manas Ghandat wrote:
> I was wondering if we could implement a get_tree_size macro wherein  we 
> could find the tree size so that we can do the comparison. SInce the 
> tp->dmt_stree is an array we can get its size and fix the out of bounds. 
> Would this thing work?

dmtree_t is a union of two nearly identical structures that both contain 
an stree. The only real difference in the structures is the size of the 
stree, so dbFindLeaf doesn't really know which is being used by the caller.

> 
> On 30/08/23 00:08, Dave Kleikamp wrote:
>> This won't work. dbFindLeaf() can be called from dbFindCtl() with 
>> struct dmapctl whose stree index can be as high as CTLTREESIZE which 
>> is larger than TREESIZE. A check against CTLTREESIZE might be better 
>> than nothing at all but won't necessarily detect an overflow. 
>> Currently, dbFindLeaf doesn't have anything to tell it which tree it 
>> is working on.
>>
>> We could pass in the treesize as an argument to dbFindCtl() if we 
>> can't come up with something simpler.
>>
>> Shaggy
>>
>>>
>>> Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com>
>>> Reported-by: syzbot+aea1ad91e854d0a83e04@syzkaller.appspotmail.com
>>> Closes: https://syzkaller.appspot.com/bug?extid=aea1ad91e854d0a83e04
>>> ---
>>>   fs/jfs/jfs_dmap.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
>>> index a14a0f18a4c4..5af17b2287be 100644
>>> --- a/fs/jfs/jfs_dmap.c
>>> +++ b/fs/jfs/jfs_dmap.c
>>> @@ -2948,6 +2948,10 @@ static int dbFindLeaf(dmtree_t * tp, int l2nb, 
>>> int *leafidx)
>>>               /* sufficient free space found.  move to the next
>>>                * level (or quit if this is the last level).
>>>                */
>>> +
>>> +            if (x + n > TREESIZE)
>>> +                return -ENOSPC;
>>> +
>>>               if (l2nb <= tp->dmt_stree[x + n])
>>>                   break;
>>>           }

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

[Manas Ghandat]

Actually I was talking about the stree attribute of dmtree which is 
present in both dmaptree and dmapctl.

Link : https://elixir.bootlin.com/linux/v6.5.1/source/fs/jfs/jfs_dmap.h#L168

Since it is an array we can add a check for the size of array like the 
code below.


+            if (x + n > (sizeof(tp->dmt_stree)/sizeof(s8)))
+                 return -ENOSPC;

On 01/09/23 22:38, Dave Kleikamp wrote:
> On 8/31/23 10:19AM, Manas Ghandat wrote:
>> I was wondering if we could implement a get_tree_size macro wherein  
>> we could find the tree size so that we can do the comparison. SInce 
>> the tp->dmt_stree is an array we can get its size and fix the out of 
>> bounds. Would this thing work?
>
> dmtree_t is a union of two nearly identical structures that both 
> contain an stree. The only real difference in the structures is the 
> size of the stree, so dbFindLeaf doesn't really know which is being 
> used by the caller.
>

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

[Dave Kleikamp]

On 9/2/23 12:45PM, Manas Ghandat wrote:
> Actually I was talking about the stree attribute of dmtree which is 
> present in both dmaptree and dmapctl.
> 
> Link : 
> https://elixir.bootlin.com/linux/v6.5.1/source/fs/jfs/jfs_dmap.h#L168
> 
> Since it is an array we can add a check for the size of array like the 
> code below.
> 
> 
> +            if (x + n > (sizeof(tp->dmt_stree)/sizeof(s8)))
> +                 return -ENOSPC;

That will always evaluate to the same thing (the size of stree in 
dmapctl). It would be valid, since that is the larger number, but it 
wouldn't catch all overflows of dmaptree's stree.


> 
> On 01/09/23 22:38, Dave Kleikamp wrote:
>> On 8/31/23 10:19AM, Manas Ghandat wrote:
>>> I was wondering if we could implement a get_tree_size macro wherein 
>>> we could find the tree size so that we can do the comparison. SInce 
>>> the tp->dmt_stree is an array we can get its size and fix the out of 
>>> bounds. Would this thing work?
>>
>> dmtree_t is a union of two nearly identical structures that both 
>> contain an stree. The only real difference in the structures is the 
>> size of the stree, so dbFindLeaf doesn't really know which is being 
>> used by the caller.
>>

[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