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

[Dave Kleikamp <dave.kleikamp@oracle.com>]

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