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

[Dmitry Vyukov]

On Wed, 4 Feb 2026 at 10:23, syzbot <syzbot@xxxxxxxxxx> 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@xxxxxxxxxx
> Signed-off-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
> Fixes: 22cad8bc1d36 ("jfs: fix array-index-out-of-bounds in dbFindLeaf")
> Reported-by: syzbot+1afe7ef2d0062e19eeb3@xxxxxxxxxxxxxxxxxxxxxxxxx
> To: <jfs-discussion@xxxxxxxxxxxxxxxxxxxxx>
> To: "Dave Kleikamp" <shaggy@xxxxxxxxxx>
> To: "Manas Ghandat" <ghandatmanas@xxxxxxxxx>
> Cc: <linux-kernel@xxxxxxxxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx>
> ---
> 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?