Re: [PATCH] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree

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

On 10/11/23 1:46PM, Osama Muhammad wrote:
> Syzkaller reported the following issue:
> 
> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
> index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
> CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:88 [inline]
>   dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
>   ubsan_epilogue lib/ubsan.c:217 [inline]
>   __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
>   dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
>   dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
>   dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
>   dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
>   dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
>   txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
>   txUpdateMap+0x342/0x9e0
>   txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
>   jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
>   kthread+0x2d3/0x370 kernel/kthread.c:388
>   ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>   </TASK>
> ================================================================================
> Kernel panic - not syncing: UBSAN: panic_on_warn set ...
> CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:88 [inline]
>   dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
>   panic+0x30f/0x770 kernel/panic.c:340
>   check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
>   ubsan_epilogue lib/ubsan.c:223 [inline]
>   __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
>   dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
>   dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
>   dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
>   dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
>   dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
>   txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
>   txUpdateMap+0x342/0x9e0
>   txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
>   jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
>   kthread+0x2d3/0x370 kernel/kthread.c:388
>   ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>   </TASK>
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> The issue is caused when the value of lp becomes greater than
> CTLTREESIZE which is the max size of stree. Adding a simple check
> solves this issue. I was not sure about error return as a function
> does not return. If there is something needed in that regard please
> do point out.

There isn't too much we can do here without a bit of a code reorg. Even 
the calling functions are void. We can't mark the filesystem dirty 
easily either because we don't have a way to get to the superblock from 
this function. I think I will change the test to
if (WARN_ON_ONCE(lp >= CTLTREESIZE))
for the lack of a better option.

Shaggy

> 
> The patch is tested via syzbot.
> 
> Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb
> Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
> ---
>   fs/jfs/jfs_dmap.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index a3eb1e826947..decb3be66a86 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -2854,6 +2854,9 @@ static void dbAdjTree(dmtree_t * tp, int leafno, int newval)
>   	/* is the current value the same as the old value ?  if so,
>   	 * there is nothing to do.
>   	 */
> +	if (lp >= CTLTREESIZE)
> +		return;
> +
>   	if (tp->dmt_stree[lp] == newval)
>   		return;
>