From: Ivan Orlov <ivan.orlov0322@gmail.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] gfs2 FS: Fix UBSAN array-index-out-of-bounds in __gfs2_iomap_get
Date: Wed, 15 Mar 2023 13:12:47 +0400 [thread overview]
Message-ID: <97abb511-9918-4df5-e421-835b4ecd324c@gmail.com> (raw)
In-Reply-To: <20230315090620.7294-1-ivan.orlov0322@gmail.com>
On 3/15/23 13:06, Ivan Orlov wrote:
> Syzkaller reported the following issue:
>
> UBSAN: array-index-out-of-bounds in fs/gfs2/bmap.c:901:46
> index 11 is out of range for type 'u64 [11]'
> CPU: 0 PID: 5067 Comm: syz-executor164 Not tainted 6.1.0-syzkaller-13031-g77856d911a8c #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
> ubsan_epilogue lib/ubsan.c:151 [inline]
> __ubsan_handle_out_of_bounds+0xe0/0x110 lib/ubsan.c:282
> __gfs2_iomap_get+0x4a4/0x16e0 fs/gfs2/bmap.c:901
> gfs2_iomap_get fs/gfs2/bmap.c:1399 [inline]
> gfs2_block_map+0x28f/0x7f0 fs/gfs2/bmap.c:1214
> gfs2_write_alloc_required+0x441/0x6e0 fs/gfs2/bmap.c:2322
> gfs2_jdesc_check+0x1b9/0x290 fs/gfs2/super.c:114
> init_journal+0x5a4/0x22c0 fs/gfs2/ops_fstype.c:804
> init_inodes+0xdc/0x340 fs/gfs2/ops_fstype.c:889
> gfs2_fill_super+0x1bb2/0x2700 fs/gfs2/ops_fstype.c:1247
> get_tree_bdev+0x400/0x620 fs/super.c:1282
> gfs2_get_tree+0x50/0x210 fs/gfs2/ops_fstype.c:1330
> vfs_get_tree+0x88/0x270 fs/super.c:1489
> do_new_mount+0x289/0xad0 fs/namespace.c:3145
> do_mount fs/namespace.c:3488 [inline]
> __do_sys_mount fs/namespace.c:3697 [inline]
> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f2c63567aca
> Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 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:00007ffd0e3a28d8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2c63567aca
> RDX: 0000000020037f40 RSI: 0000000020037f80 RDI: 00007ffd0e3a28e0
> RBP: 00007ffd0e3a28e0 R08: 00007ffd0e3a2920 R09: 0000000000043350
> R10: 0000000002000011 R11: 0000000000000282 R12: 0000000000000004
> R13: 00005555567192c0 R14: 00007ffd0e3a2920 R15: 0000000000000000
> </TASK>
>
> This issue is caused by the 'while' loop in the '__gfs2_iomap_get' function,
> which increments 'height' var until it matches the condition. If height is
> larger or equal to 'sdp->sd_heightsize' array size (which is GFS2_MAX_META_HEIGHT
> + 1), the array-index-out-of-bounds issue occurs. Therefore we need to add extra
> condition to the while loop, which will prevent this issue.
>
> Additionally, if 'height' var after the while ending is equal to GFS2_MAX_META_HEIGHT,
> the 'find_metapath' call right after the loop will break (because it assumes that
> 'height' parameter will not be larger than the size of metapath's mp_list array length,
> which is GFS2_MAX_META_HEIGHT). So, we need to check the 'height' after the loop ending,
> and if its value is too big we need to break the execution of the function, and return
> a proper error if it is too big.
>
> Tested via syzbot.
>
> Reported-by: syzbot+45d4691b1ed3c48eba05 at syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?id=42296ea544c870f4dde3b25efa4cc1b89515d38e
> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
> ---
> fs/gfs2/bmap.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index eedf6926c652..9b7358165f96 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -895,8 +895,16 @@ static int __gfs2_iomap_get(struct inode *inode, loff_t pos, loff_t length,
> iomap->length = len << inode->i_blkbits;
>
> height = ip->i_height;
> - while ((lblock + 1) * sdp->sd_sb.sb_bsize > sdp->sd_heightsize[height])
> +
> + while (height <= GFS2_MAX_META_HEIGHT
> + && (lblock + 1) * sdp->sd_sb.sb_bsize > sdp->sd_heightsize[height])
> height++;
> +
> + if (height > GFS2_MAX_META_HEIGHT) {
> + ret = -ERANGE;
> + goto unlock;
> + }
> +
> find_metapath(sdp, lblock, mp, height);
> if (height > ip->i_height || gfs2_is_stuffed(ip))
> goto do_alloc;
Upd. I made a typo in the second paragraph of patch description: the
'find_metapath' call will break if height is larger than
GFS2_MAX_META_HEIGHT, not equal to. So this I check in corresponding
condition right after the while loop.
WARNING: multiple messages have this Message-ID (diff)
From: Ivan Orlov <ivan.orlov0322@gmail.com>
To: rpeterso@redhat.com, agruenba@redhat.com
Cc: linux-kernel@vger.kernel.org,
syzbot+45d4691b1ed3c48eba05@syzkaller.appspotmail.com,
cluster-devel@redhat.com,
linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [PATCH] gfs2 FS: Fix UBSAN array-index-out-of-bounds in __gfs2_iomap_get
Date: Wed, 15 Mar 2023 13:12:47 +0400 [thread overview]
Message-ID: <97abb511-9918-4df5-e421-835b4ecd324c@gmail.com> (raw)
In-Reply-To: <20230315090620.7294-1-ivan.orlov0322@gmail.com>
On 3/15/23 13:06, Ivan Orlov wrote:
> Syzkaller reported the following issue:
>
> UBSAN: array-index-out-of-bounds in fs/gfs2/bmap.c:901:46
> index 11 is out of range for type 'u64 [11]'
> CPU: 0 PID: 5067 Comm: syz-executor164 Not tainted 6.1.0-syzkaller-13031-g77856d911a8c #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
> ubsan_epilogue lib/ubsan.c:151 [inline]
> __ubsan_handle_out_of_bounds+0xe0/0x110 lib/ubsan.c:282
> __gfs2_iomap_get+0x4a4/0x16e0 fs/gfs2/bmap.c:901
> gfs2_iomap_get fs/gfs2/bmap.c:1399 [inline]
> gfs2_block_map+0x28f/0x7f0 fs/gfs2/bmap.c:1214
> gfs2_write_alloc_required+0x441/0x6e0 fs/gfs2/bmap.c:2322
> gfs2_jdesc_check+0x1b9/0x290 fs/gfs2/super.c:114
> init_journal+0x5a4/0x22c0 fs/gfs2/ops_fstype.c:804
> init_inodes+0xdc/0x340 fs/gfs2/ops_fstype.c:889
> gfs2_fill_super+0x1bb2/0x2700 fs/gfs2/ops_fstype.c:1247
> get_tree_bdev+0x400/0x620 fs/super.c:1282
> gfs2_get_tree+0x50/0x210 fs/gfs2/ops_fstype.c:1330
> vfs_get_tree+0x88/0x270 fs/super.c:1489
> do_new_mount+0x289/0xad0 fs/namespace.c:3145
> do_mount fs/namespace.c:3488 [inline]
> __do_sys_mount fs/namespace.c:3697 [inline]
> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f2c63567aca
> Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 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:00007ffd0e3a28d8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2c63567aca
> RDX: 0000000020037f40 RSI: 0000000020037f80 RDI: 00007ffd0e3a28e0
> RBP: 00007ffd0e3a28e0 R08: 00007ffd0e3a2920 R09: 0000000000043350
> R10: 0000000002000011 R11: 0000000000000282 R12: 0000000000000004
> R13: 00005555567192c0 R14: 00007ffd0e3a2920 R15: 0000000000000000
> </TASK>
>
> This issue is caused by the 'while' loop in the '__gfs2_iomap_get' function,
> which increments 'height' var until it matches the condition. If height is
> larger or equal to 'sdp->sd_heightsize' array size (which is GFS2_MAX_META_HEIGHT
> + 1), the array-index-out-of-bounds issue occurs. Therefore we need to add extra
> condition to the while loop, which will prevent this issue.
>
> Additionally, if 'height' var after the while ending is equal to GFS2_MAX_META_HEIGHT,
> the 'find_metapath' call right after the loop will break (because it assumes that
> 'height' parameter will not be larger than the size of metapath's mp_list array length,
> which is GFS2_MAX_META_HEIGHT). So, we need to check the 'height' after the loop ending,
> and if its value is too big we need to break the execution of the function, and return
> a proper error if it is too big.
>
> Tested via syzbot.
>
> Reported-by: syzbot+45d4691b1ed3c48eba05@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?id=42296ea544c870f4dde3b25efa4cc1b89515d38e
> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
> ---
> fs/gfs2/bmap.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index eedf6926c652..9b7358165f96 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -895,8 +895,16 @@ static int __gfs2_iomap_get(struct inode *inode, loff_t pos, loff_t length,
> iomap->length = len << inode->i_blkbits;
>
> height = ip->i_height;
> - while ((lblock + 1) * sdp->sd_sb.sb_bsize > sdp->sd_heightsize[height])
> +
> + while (height <= GFS2_MAX_META_HEIGHT
> + && (lblock + 1) * sdp->sd_sb.sb_bsize > sdp->sd_heightsize[height])
> height++;
> +
> + if (height > GFS2_MAX_META_HEIGHT) {
> + ret = -ERANGE;
> + goto unlock;
> + }
> +
> find_metapath(sdp, lblock, mp, height);
> if (height > ip->i_height || gfs2_is_stuffed(ip))
> goto do_alloc;
Upd. I made a typo in the second paragraph of patch description: the
'find_metapath' call will break if height is larger than
GFS2_MAX_META_HEIGHT, not equal to. So this I check in corresponding
condition right after the while loop.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
WARNING: multiple messages have this Message-ID (diff)
From: Ivan Orlov <ivan.orlov0322@gmail.com>
To: rpeterso@redhat.com, agruenba@redhat.com
Cc: cluster-devel@redhat.com, linux-kernel@vger.kernel.org,
skhan@linuxfoundation.org, himadrispandya@gmail.com,
linux-kernel-mentees@lists.linuxfoundation.org,
syzbot+45d4691b1ed3c48eba05@syzkaller.appspotmail.com
Subject: Re: [PATCH] gfs2 FS: Fix UBSAN array-index-out-of-bounds in __gfs2_iomap_get
Date: Wed, 15 Mar 2023 13:12:47 +0400 [thread overview]
Message-ID: <97abb511-9918-4df5-e421-835b4ecd324c@gmail.com> (raw)
In-Reply-To: <20230315090620.7294-1-ivan.orlov0322@gmail.com>
On 3/15/23 13:06, Ivan Orlov wrote:
> Syzkaller reported the following issue:
>
> UBSAN: array-index-out-of-bounds in fs/gfs2/bmap.c:901:46
> index 11 is out of range for type 'u64 [11]'
> CPU: 0 PID: 5067 Comm: syz-executor164 Not tainted 6.1.0-syzkaller-13031-g77856d911a8c #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
> ubsan_epilogue lib/ubsan.c:151 [inline]
> __ubsan_handle_out_of_bounds+0xe0/0x110 lib/ubsan.c:282
> __gfs2_iomap_get+0x4a4/0x16e0 fs/gfs2/bmap.c:901
> gfs2_iomap_get fs/gfs2/bmap.c:1399 [inline]
> gfs2_block_map+0x28f/0x7f0 fs/gfs2/bmap.c:1214
> gfs2_write_alloc_required+0x441/0x6e0 fs/gfs2/bmap.c:2322
> gfs2_jdesc_check+0x1b9/0x290 fs/gfs2/super.c:114
> init_journal+0x5a4/0x22c0 fs/gfs2/ops_fstype.c:804
> init_inodes+0xdc/0x340 fs/gfs2/ops_fstype.c:889
> gfs2_fill_super+0x1bb2/0x2700 fs/gfs2/ops_fstype.c:1247
> get_tree_bdev+0x400/0x620 fs/super.c:1282
> gfs2_get_tree+0x50/0x210 fs/gfs2/ops_fstype.c:1330
> vfs_get_tree+0x88/0x270 fs/super.c:1489
> do_new_mount+0x289/0xad0 fs/namespace.c:3145
> do_mount fs/namespace.c:3488 [inline]
> __do_sys_mount fs/namespace.c:3697 [inline]
> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f2c63567aca
> Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 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:00007ffd0e3a28d8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2c63567aca
> RDX: 0000000020037f40 RSI: 0000000020037f80 RDI: 00007ffd0e3a28e0
> RBP: 00007ffd0e3a28e0 R08: 00007ffd0e3a2920 R09: 0000000000043350
> R10: 0000000002000011 R11: 0000000000000282 R12: 0000000000000004
> R13: 00005555567192c0 R14: 00007ffd0e3a2920 R15: 0000000000000000
> </TASK>
>
> This issue is caused by the 'while' loop in the '__gfs2_iomap_get' function,
> which increments 'height' var until it matches the condition. If height is
> larger or equal to 'sdp->sd_heightsize' array size (which is GFS2_MAX_META_HEIGHT
> + 1), the array-index-out-of-bounds issue occurs. Therefore we need to add extra
> condition to the while loop, which will prevent this issue.
>
> Additionally, if 'height' var after the while ending is equal to GFS2_MAX_META_HEIGHT,
> the 'find_metapath' call right after the loop will break (because it assumes that
> 'height' parameter will not be larger than the size of metapath's mp_list array length,
> which is GFS2_MAX_META_HEIGHT). So, we need to check the 'height' after the loop ending,
> and if its value is too big we need to break the execution of the function, and return
> a proper error if it is too big.
>
> Tested via syzbot.
>
> Reported-by: syzbot+45d4691b1ed3c48eba05@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?id=42296ea544c870f4dde3b25efa4cc1b89515d38e
> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
> ---
> fs/gfs2/bmap.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index eedf6926c652..9b7358165f96 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -895,8 +895,16 @@ static int __gfs2_iomap_get(struct inode *inode, loff_t pos, loff_t length,
> iomap->length = len << inode->i_blkbits;
>
> height = ip->i_height;
> - while ((lblock + 1) * sdp->sd_sb.sb_bsize > sdp->sd_heightsize[height])
> +
> + while (height <= GFS2_MAX_META_HEIGHT
> + && (lblock + 1) * sdp->sd_sb.sb_bsize > sdp->sd_heightsize[height])
> height++;
> +
> + if (height > GFS2_MAX_META_HEIGHT) {
> + ret = -ERANGE;
> + goto unlock;
> + }
> +
> find_metapath(sdp, lblock, mp, height);
> if (height > ip->i_height || gfs2_is_stuffed(ip))
> goto do_alloc;
Upd. I made a typo in the second paragraph of patch description: the
'find_metapath' call will break if height is larger than
GFS2_MAX_META_HEIGHT, not equal to. So this I check in corresponding
condition right after the while loop.
next prev parent reply other threads:[~2023-03-15 9:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 9:06 [Cluster-devel] [PATCH] gfs2 FS: Fix UBSAN array-index-out-of-bounds in __gfs2_iomap_get Ivan Orlov
2023-03-15 9:06 ` Ivan Orlov
2023-03-15 9:06 ` Ivan Orlov
2023-03-15 9:12 ` Ivan Orlov [this message]
2023-03-15 9:12 ` Ivan Orlov
2023-03-15 9:12 ` Ivan Orlov
2023-03-27 23:10 ` [Cluster-devel] " Andreas Gruenbacher
2023-03-27 23:10 ` Andreas Gruenbacher
2023-03-27 23:10 ` Andreas Gruenbacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97abb511-9918-4df5-e421-835b4ecd324c@gmail.com \
--to=ivan.orlov0322@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.