在 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
