On Mon, Jun 6, 2022 at 10:40 AM Qian Cai <quic_qiancai@xxxxxxxxxxx> wrote:
>
> On Mon, Jun 06, 2022 at 04:19:52PM +0000, Liam Howlett wrote:
> > Does your syscall fuzzer create a reproducer? This looks like arm64
> > and says 5.18.0-next-20220603 again. Was this bisected to the patch
> > above?
>
> This was triggered by running the fuzzer over the weekend.
>
> $ trinity -C 160
>
> No bisection was done. It was only brought up here because the trace
> pointed to do_mas_munmap() which was introduced here.
Liam,
I'm getting a similar crash on arm64 -- the allocator is madvise(),
not mprotect(). Please take a look.
Thanks.
==================================================================
BUG: KASAN: double-free or invalid-free in kmem_cache_free_bulk+0x230/0x3b0
Pointer tag: [0c], memory tag: [fe]
CPU: 2 PID: 8320 Comm: stress-ng Tainted: G B W
5.19.0-rc1-lockdep+ #3
Call trace:
dump_backtrace+0x1a0/0x200
show_stack+0x24/0x30
dump_stack_lvl+0x7c/0xa0
print_report+0x15c/0x524
kasan_report_invalid_free+0x64/0x84
____kasan_slab_free+0x150/0x184
__kasan_slab_free+0x14/0x24
slab_free_freelist_hook+0x100/0x1ac
kmem_cache_free_bulk+0x230/0x3b0
mas_destroy+0x10d8/0x1270
mas_store_prealloc+0xb8/0xec
do_mas_align_munmap+0x398/0x694
do_mas_munmap+0xf8/0x118
__vm_munmap+0x154/0x1e0
__arm64_sys_munmap+0x44/0x54
el0_svc_common+0xfc/0x1cc
do_el0_svc_compat+0x38/0x5c
el0_svc_compat+0x68/0xf4
el0t_32_sync_handler+0xc0/0xf0
el0t_32_sync+0x190/0x194
Allocated by task 8437:
kasan_set_track+0x4c/0x7c
__kasan_slab_alloc+0x84/0xa8
kmem_cache_alloc_bulk+0x300/0x408
mas_alloc_nodes+0x198/0x294
mas_preallocate+0x8c/0x110
__vma_adjust+0x174/0xc88
vma_merge+0x2e4/0x300
do_madvise+0x504/0xd20
__arm64_sys_madvise+0x54/0x64
el0_svc_common+0xfc/0x1cc
do_el0_svc_compat+0x38/0x5c
el0_svc_compat+0x68/0xf4
el0t_32_sync_handler+0xc0/0xf0
el0t_32_sync+0x190/0x194
Freed by task 8320:
kasan_set_track+0x4c/0x7c
kasan_set_free_info+0x2c/0x38
____kasan_slab_free+0x13c/0x184
__kasan_slab_free+0x14/0x24
slab_free_freelist_hook+0x100/0x1ac
kmem_cache_free+0x11c/0x264
mt_destroy_walk+0x6d8/0x714
mas_wmb_replace+0x9d4/0xa68
mas_spanning_rebalance+0x1af0/0x1d2c
mas_wr_spanning_store+0x908/0x964
mas_wr_store_entry+0x53c/0x5c0
mas_store_prealloc+0x88/0xec
do_mas_align_munmap+0x398/0x694
do_mas_munmap+0xf8/0x118
__vm_munmap+0x154/0x1e0
__arm64_sys_munmap+0x44/0x54
el0_svc_common+0xfc/0x1cc
do_el0_svc_compat+0x38/0x5c
el0_svc_compat+0x68/0xf4
el0t_32_sync_handler+0xc0/0xf0
el0t_32_sync+0x190/0x194
The buggy address belongs to the object at ffffff808b5f0a00
which belongs to the cache maple_node of size 256
The buggy address is located 0 bytes inside of
256-byte region [ffffff808b5f0a00, ffffff808b5f0b00)
The buggy address belongs to the physical page:
page:fffffffe022d7c00 refcount:1 mapcount:0 mapping:0000000000000000
index:0xcffff808b5f0a00 pfn:0x10b5f0
head:fffffffe022d7c00 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x8000000000010200(slab|head|zone=2|kasantag=0x0)
raw: 8000000000010200 fffffffe031a8608 fffffffe021a3608 caffff808002c800
raw: 0cffff808b5f0a00 0000000000150013 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffff808b5f0800: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
ffffff808b5f0900: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>ffffff808b5f0a00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
^
ffffff808b5f0b00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
ffffff808b5f0c00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
==================================================================
