Re: [PATCH] fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev

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

On 6/21/23 1:37PM, Yogesh wrote:
> Syzkaller reported the following issue:
> 
> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6
> index -84 is out of range for type 's8[341]' (aka 'signed char[341]')
> CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/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
>   dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965
>   dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809
>   dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350
>   dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874
>   dtSplitUp fs/jfs/jfs_dtree.c:974 [inline]
>   dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863
>   jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137
>   lookup_open fs/namei.c:3492 [inline]
>   open_last_lookups fs/namei.c:3560 [inline]
>   path_openat+0x13df/0x3170 fs/namei.c:3788
>   do_filp_open+0x234/0x490 fs/namei.c:3818
>   do_sys_openat2+0x13f/0x500 fs/open.c:1356
>   do_sys_open fs/open.c:1372 [inline]
>   __do_sys_openat fs/open.c:1388 [inline]
>   __se_sys_openat fs/open.c:1383 [inline]
>   __x64_sys_openat+0x247/0x290 fs/open.c:1383
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f1f4e33f7e9
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f4e33f7e9
> RDX: 000000000000275a RSI: 0000000020000040 RDI: 00000000ffffff9c
> RBP: 00007f1f4e2ff080 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1f4e2ff110
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>   </TASK>
> 
> The bug occurs when the dbAllocDmapLev()function attempts to access
> dp->tree.stree[leafidx + LEAFIND] while the leafidx value is negative.
> 
> To rectify this, the patch introduces a safeguard within the
> dbAllocDmapLev() function. A check has been added to verify if leafidx is
> negative. If it is, the function immediately returns an I/O error, preventing
> any further execution that could potentially cause harm.
> 
> Tested via syzbot.

All this code could be made more robust, but this is good enough for now.

Added to jfs-next.

Thanks,
Shaggy

> 
> Reported-by: syzbot+853a6f4dfa3cf37d3aea@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=ae2f5a27a07ae44b0f17
> Signed-off-by: Yogesh <yogi.kernel@gmail.com>
> ---
>   fs/jfs/jfs_dmap.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index a3eb1e826947..839f1b67485f 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -1953,6 +1953,8 @@ dbAllocDmapLev(struct bmap * bmp,
>   	if (dbFindLeaf((dmtree_t *) & dp->tree, l2nb, &leafidx))
>   		return -ENOSPC;
>   
> +	if (leafidx < 0)
> +		return -EIO;
>   	/* determine the block number within the file system corresponding
>   	 * to the leaf at which free space was found.
>   	 */