On Tue, Nov 23, 2021 at 10:32:20PM +0800, Kefeng Wang wrote:
> Yongqiang reports a kmemleak panic when module insmod/rmmod with KASAN
> enabled on x86[1].
>
> When the module allocates memory, it's kmemleak_object is created successfully,
> but the KASAN shadow memory of module allocation is not ready, so when kmemleak
> scan the module's pointer, it will panic due to no shadow memory with KASAN.
>
> module_alloc
> __vmalloc_node_range
> kmemleak_vmalloc
> kmemleak_scan
> update_checksum
> kasan_module_alloc
> kmemleak_ignore
Can you share the .config and the stack trace you get on arm64?
I have a suspicion there is no problem if KASAN_VMALLOC is enabled.
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index 4a4929b29a23..2ade2f484562 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -498,7 +498,7 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end,
>
> #else /* CONFIG_KASAN_VMALLOC */
>
> -int kasan_module_alloc(void *addr, size_t size)
> +int kasan_module_alloc(void *addr, size_t size, gfp_t gfp_mask)
> {
> void *ret;
> size_t scaled_size;
> @@ -520,9 +520,14 @@ int kasan_module_alloc(void *addr, size_t size)
> __builtin_return_address(0));
>
> if (ret) {
> + struct vm_struct *vm = find_vm_area(addr);
> __memset(ret, KASAN_SHADOW_INIT, shadow_size);
> - find_vm_area(addr)->flags |= VM_KASAN;
> + vm->flags |= VM_KASAN;
> kmemleak_ignore(ret);
> +
> + if (vm->flags & VM_DELAY_KMEMLEAK)
> + kmemleak_vmalloc(vm, size, gfp_mask);
> +
> return 0;
> }
This function only exists if CONFIG_KASAN_VMALLOC=n.
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index d2a00ad4e1dd..23c595b15839 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3074,7 +3074,8 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
> clear_vm_uninitialized_flag(area);
>
> size = PAGE_ALIGN(size);
> - kmemleak_vmalloc(area, size, gfp_mask);
> + if (!(vm_flags & VM_DELAY_KMEMLEAK))
> + kmemleak_vmalloc(area, size, gfp_mask);
So with KASAN_VMALLOC enabled, we'll miss the kmemleak allocation.
You could add an IS_ENABLED(CONFIG_KASAN_VMALLOC) check but I'm not
particularly fond of the delay approach (also think DEFER is probably a
better name).
A quick fix would be to make KMEMLEAK depend on !KASAN || KASAN_VMALLOC.
We'll miss KASAN_SW_TAGS with kmemleak but I think vmalloc support could
be enabled for this as well.
What does KASAN do with other vmalloc() allocations when !KASAN_VMALLOC?
Can we not have a similar approach. I don't fully understand why the
module vmalloc() is a special case.
--
Catalin
