[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fdb94432-a14f-32c1-3e75-697924f76f25@oracle.com>
Date: Thu, 22 Jun 2023 10:59:36 -0500
From: Dave Kleikamp <dave.kleikamp@...cle.com>
To: Yogesh <yogi.kernel@...il.com>, shaggy@...nel.org,
jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Cc: linux-kernel-mentees@...ts.linuxfoundation.org,
skhan@...uxfoundation.org, ivan.orlov0322@...il.com
Subject: Re: [PATCH] fs: jfs: Fix UBSAN: array-index-out-of-bounds in
dbAllocDmapLev
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@...kaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=ae2f5a27a07ae44b0f17
> Signed-off-by: Yogesh <yogi.kernel@...il.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.
> */
Powered by blists - more mailing lists