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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <023311e6-9666-4fe0-9c22-6a8409065539@suse.com>
Date: Fri, 20 Dec 2024 10:03:08 +1030
From: Qu Wenruo <wqu@...e.com>
To: Dan Carpenter <dan.carpenter@...aro.org>,
 Qu Wenruo <quwenruo.btrfs@....com>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>, qemu-devel@...gnu.org,
 open list <linux-kernel@...r.kernel.org>,
 Linux Regressions <regressions@...ts.linux.dev>,
 linux-ext4 <linux-ext4@...r.kernel.org>, lkft-triage@...ts.linaro.org,
 linux-mm <linux-mm@...ck.org>, Linux btrfs <linux-btrfs@...r.kernel.org>,
 Alex Bennée <alex.bennee@...aro.org>,
 Anders Roxell <anders.roxell@...aro.org>, Arnd Bergmann <arnd@...db.de>,
 David Sterba <dsterba@...e.com>
Subject: Re: qemu-arm64: CONFIG_ARM64_64K_PAGES=y kernel crash on qemu-arm64
 with Linux next-20241210 and above



在 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