Re: qemu-arm64: CONFIG_ARM64_64K_PAGES=y kernel crash on qemu-arm64 with Linux next-20241210 and above

[Qu Wenruo <wqu@suse.com>]

在 2024/12/20 02:07, Dan Carpenter 写道:
> On Thu, Dec 19, 2024 at 06:10:56PM +0300, Dan Carpenter wrote:
>>>> Mind to test it with KASAN enabled?
>>>
>>
>> Anders is going to try that later and report back.
>>
> 
> Anders ran it and emailed me.  I was going to tell him to respond to
> the thread but I decided to steal the credit.  #GreatArtists
> 
>   BTRFS info (device loop0): using crc32c (crc32c-arm64) checksum algorithm
>   ==================================================================
>   BUG: KASAN: slab-out-of-bounds in __bitmap_set+0xf8/0x100
>   Read of size 8 at addr fff0000020e4a3c8 by task chdir01/479
>   
>   CPU: 1 UID: 0 PID: 479 Comm: chdir01 Not tainted 6.13.0-rc3-next-20241218 #1
>   Hardware name: linux,dummy-virt (DT)
>   Call trace:
>    show_stack+0x20/0x38 (C)
>    dump_stack_lvl+0x8c/0xd0
>    print_report+0x118/0x5e0
>    kasan_report+0xb4/0x100
>    __asan_report_load8_noabort+0x20/0x30
>    __bitmap_set+0xf8/0x100
>    btrfs_subpage_set_uptodate+0xd8/0x1d0 [btrfs]
>    set_extent_buffer_uptodate+0x1ac/0x288 [btrfs]
>    __alloc_dummy_extent_buffer+0x2cc/0x488 [btrfs]

Thanks a lot. The problem is still inside the dummy extent buffer 
allocation.

This time it's again related to the uninitialized fs_info->* variables.

In this case, it's the fs_info->sectorsize_bits which is not 
initialized, thus its default value is 0.

Then in btrfs_subpage_set_uptodate(), we use (len >> sectorsize_bits) to 
calculate how many bits must be set.

But since sectorsize_bits is 0, the @len (4K) is utilized, resulting the 
out-of-boundary access.

The root cause is the same as the initial failure, that we can not use a 
lot of functions to do such early verification, thus I'll create a 
dedicated helper to do the sanity check to avoid memory allocation nor 
early access to fs_info.

Thanks everyone involved in exposing this bug!
Qu

>    alloc_dummy_extent_buffer+0x4c/0x78 [btrfs]
>    btrfs_check_system_chunk_array+0x30/0x308 [btrfs]
>    btrfs_validate_super+0x7e8/0xd40 [btrfs]
>    open_ctree+0x958/0x3c98 [btrfs]
>    btrfs_get_tree+0xce4/0x13d8 [btrfs]
>    vfs_get_tree+0x7c/0x290
>    fc_mount+0x20/0xa8
>    btrfs_get_tree+0x72c/0x13d8 [btrfs]
>    vfs_get_tree+0x7c/0x290
>    path_mount+0x748/0x1518
>    __arm64_sys_mount+0x234/0x4f8
>    invoke_syscall.constprop.0+0x78/0x1f0
>    do_el0_svc+0xcc/0x1d8
>    el0_svc+0x38/0xa8
>    el0t_64_sync_handler+0x10c/0x138
>    el0t_64_sync+0x198/0x1a0
> 
> Here are the full logs.
> https://people.linaro.org/~anders.roxell/next-20241218-issue-arm64-64k+kasan/
> 
> regards,
> dan carpenter