Messages in this thread | | | Date | Wed, 24 Nov 2021 13:50:14 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH v3] mm: Defer kmemleak object creation of module_alloc() |
| |
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?
| |