在 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