All of lore.kernel.org
 help / color / mirror / Atom feed
From: "yebin (H)" <yebin10@huawei.com>
To: Ye Bin <yebin@huaweicloud.com>, <tytso@mit.edu>,
	<adilger.kernel@dilger.ca>, <linux-ext4@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <jack@suse.cz>,
	<syzbot+bf4bb7731ef73b83a3b4@syzkaller.appspotmail.com>
Subject: Re: [PATCH] ext4: fix use-after-free Read in ext4_find_extent for bigalloc + inline
Date: Fri, 3 Mar 2023 09:12:13 +0800	[thread overview]
Message-ID: <6401496D.2090308@huawei.com> (raw)
In-Reply-To: <20230104071559.2051847-1-yebin@huaweicloud.com>

ping...

On 2023/1/4 15:15, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> Syzbot found the following issue:
> loop0: detected capacity change from 0 to 2048
> EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
> ==================================================================
> BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]
> BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931
> Read of size 4 at addr ffff888073644750 by task syz-executor420/5067
>
> CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #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
>   print_address_description+0x74/0x340 mm/kasan/report.c:306
>   print_report+0x107/0x1f0 mm/kasan/report.c:417
>   kasan_report+0xcd/0x100 mm/kasan/report.c:517
>   ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]
>   ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931
>   ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809
>   ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline]
>   ext4_da_map_blocks fs/ext4/inode.c:1806 [inline]
>   ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870
>   ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098
>   ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082
>   generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
>   ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285
>   ext4_file_write_iter+0x1d0/0x18f0
>   call_write_iter include/linux/fs.h:2186 [inline]
>   new_sync_write fs/read_write.c:491 [inline]
>   vfs_write+0x7dc/0xc50 fs/read_write.c:584
>   ksys_write+0x177/0x2a0 fs/read_write.c:637
>   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:0x7f4b7a9737b9
> RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9
> RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004
> RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000
> R10: 000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>   </TASK>
>
> Above issue is happens when enable bigalloc and inline data feature. As
> commit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped for
> bigalloc + inline. But it only resolved issue when has inline data, if
> inline data has been converted to extent(ext4_da_convert_inline_data_to_extent)
> before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. However
> i_data is still store inline data in this scene. Then will trigger UAF
> when find extent.
> To resolve above issue, there is need to add judge "ext4_has_inline_data(inode)"
> in ext4_clu_mapped().
>
> Reported-by: syzbot+bf4bb7731ef73b83a3b4@syzkaller.appspotmail.com
> Fixes: 131294c35ed6 ("ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
>   fs/ext4/extents.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 9de1c9d1a13d..ee5acf2bd5e6 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -5802,7 +5802,8 @@ int ext4_clu_mapped(struct inode *inode, ext4_lblk_t lclu)
>   	 * mapped - no physical clusters have been allocated, and the
>   	 * file has no extents
>   	 */
> -	if (ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
> +	if (ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ||
> +	    ext4_has_inline_data(inode))
>   		return 0;
>   
>   	/* search for the extent closest to the first block in the cluster */


      parent reply	other threads:[~2023-03-03  1:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04  7:15 [PATCH] ext4: fix use-after-free Read in ext4_find_extent for bigalloc + inline Ye Bin
2023-01-04  7:57 ` Tudor Ambarus
2023-01-04  8:49 ` Jan Kara
2023-03-03  1:12 ` yebin (H) [this message]

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=6401496D.2090308@huawei.com \
    --to=yebin10@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+bf4bb7731ef73b83a3b4@syzkaller.appspotmail.com \
    --cc=tytso@mit.edu \
    --cc=yebin@huaweicloud.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.