Messages in this thread | | | Date | Thu, 25 Nov 2021 09:08:59 +0800 | Subject | Re: [PATCH v3] mm: Defer kmemleak object creation of module_alloc() | From | Kefeng Wang <> |
| |
On 2021/11/25 5:50, Andrew Morton wrote: > On Wed, 24 Nov 2021 22:20:34 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> Yongqiang reports a kmemleak panic when module insmod/rmmod >> with KASAN enabled(without KASAN_VMALLOC) on x86[1]. >> >> When the module area 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 check. >> >> module_alloc >> __vmalloc_node_range >> kmemleak_vmalloc >> kmemleak_scan >> update_checksum >> kasan_module_alloc >> kmemleak_ignore >> >> Note, there is no problem if KASAN_VMALLOC enabled, the modules >> area entire shadow memory is preallocated. Thus, the bug only >> exits on ARCH which supports dynamic allocation of module area >> per module load, for now, only x86/arm64/s390 are involved. >> >> Add a VM_DEFER_KMEMLEAK flags, defer vmalloc'ed object register >> of kmemleak in module_alloc() to fix this issue. >> > I guess this is worth backporting into -stable kernels? If so, what > would be a suitable Fixes: target? I suspect it goes back to the > initial KASAN merge date?
The kasan_module_alloc() was introduced from v4.0,
s390: v4.20
793213a82de4 s390/kasan: dynamic shadow mem allocation for modules
arm64: v4.4
39d114ddc682 arm64: add KASAN support
x86: v4.0
bebf56a1b176 kasan: enable instrumentation of global variables
> .
| |