Re: [BUG] arm64: KASAN + KASLR may cause reserved page to be released during module loading

[Yang Shi]

On 9/24/25 5:41 AM, Qun-wei Lin (林群崴) wrote:
> On Fri, 2025-09-05 at 15:30 +0100, Ada Couprie Diaz wrote:
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >
> >
> > Hi,
> >
> > On 04/08/2025 15:03, Qun-wei Lin (林群崴) wrote:
> > > Hi,
> > >
> > > We have encountered a kernel panic on arm64 when loading modules
> > > with
> > > both KASAN and KASLR enabled.
> > >
> > > Kernel version:
> > > 6.12
> > > (also reproducible on 6.6-based Android common kernel)
> > >
> > > Config:
> > > CONFIG_KASAN=y
> > > CONFIG_KASAN_GENERIC=y
> > > CONFIG_KASAN_VMALLOC=y
> > > CONFIG_RANDOMIZE_BASE=y
> > > # CONFIG_RANDOMIZE_MODULE_REGION_FULL is not set
> > >
> > > Reproducible:
> > > ~50% of the time, when loading any module with Generic KASAN +
> > > KASLR
> > > enabled.
> > >
> > > The kernel panic log is as follows:
> > > [...]
> > > Comm:kworker/4:1 Tainted: G          OE      6.12.23-android16-5-
> > > g1e57f0e5996f-4k #1 eee834a579887c0f97d696d30c786233f4fbfcdf
> > > [...]
> > >
> > > If I disable KASLR, the issue does not occur.
> > With the context provided I was not able to reproduce the issue
> > when testing defconfig + generic KASAN on the following kernels :
> > - v6.17-rc4
> > - v6.12.23 Upstream
> > - v6.12.23 Android[0]
> > - v6.12.23 Upstream, compiled with LLVM
> > - v6.12.23 Android[0], compiled with LLVM
> >
> > (I tried to match the version that appears in your trace)
> >
> > I tested on both QEMU/KVM and hardware (AMD Seattle), by loading
> > and unloading an out-of-tree kernel module repeatedly (an APFS
> > driver[1]),
> > with no issues on either for all tested kernels.
> > > We are not certain which specific patch introduced this issue, but
> > > we
> > > have confirmed that it does not occur on the Android common kernel
> > > 6.1
> > > The problem was first observed after upgrading to 6.6-based
> > > kernels.
> > >
> > > Any suggestions or guidance would be appreciated.
> > > Thank you.
> > There's not much information to go off of here, my questions would be
> > :
> > - Are you able to reproduce on an upstream kernel ?
> >     (Be it from kernel.org or a "base" Android kernel, like [0])
> > - Are you able to reproduce under publicly available emulators ?
> > - Are you able to reproduce with specific, public modules ?
> >     (Something available in Debian[2] for example)
> > - Which compiler and version are you using ?
> >
> > It is a bit of work, I'm aware, but given I didn't manage to
> > reproduce
> > the issue, it would be useful to have as much info on the context
> > so either we might be able to reproduce, or you might be able to
> > pinpoint the source on your side a bit better !
> >
> > I have not seen any other reports since yours, nor did I see any
> > patch/fix
> > that seemed relevant, so I don't have much more to suggest sadly ;
> > others might.
> > > Best Regards,
> > >
> > >
> > > 林群崴 (Qun-wei Lin)
> > > Qun-wei.Lin@xxxxxxxxxxxx
> > Thanks in advance,
> > Best regards
> > Ada
> >
> >
> > [0]:
> > https://urldefense.com/v3/__https://android.googlesource.com/kernel/common/*/refs/tags/android16-6.12-2025-06_r5__;Kw!!CTRNKA9wMg0ARbw!jdaUX7F85FvZJqXX3Uhv5JtUbBtVS1J1KG-WY6odDcKfDjgJEGyCTDMUIN1DVh8uTJn0-ve1n2EjTAA11nsLXit1tcia$
> > [1]:
> > https://urldefense.com/v3/__https://github.com/linux-apfs/linux-apfs-rw/__;!!CTRNKA9wMg0ARbw!jdaUX7F85FvZJqXX3Uhv5JtUbBtVS1J1KG-WY6odDcKfDjgJEGyCTDMUIN1DVh8uTJn0-ve1n2EjTAA11nsLXmUUvNiw$
> > [2]:
> > https://urldefense.com/v3/__https://packages.debian.org/search?keywords=-dkms&searchon=names&suite=trixie&section=all__;!!CTRNKA9wMg0ARbw!jdaUX7F85FvZJqXX3Uhv5JtUbBtVS1J1KG-WY6odDcKfDjgJEGyCTDMUIN1DVh8uTJn0-ve1n2EjTAA11nsLXkz_teg4$
>
> Hi Ada,
>
> We have root-caused this.
>
> The issue is caused by an unmapped gap in the arm64 kernel segment,
> into which module allocations occasionally land.
>
> 1. map_kernel() leaves [_text, _stext) unmapped [0], so this gap is
> still available for __vmalloc_node_range.
> 2. Generic KASAN initializes shadow starting at KERNEL_START (= _text),
> so it creates shadow for that unmapped gap using early memblock pages
> (PageReserved) [1].
> 3. The module execmem region is about ~128MB; the kernel image sits
> inside that region. This means execmem_alloc() can return a VA within
> [_text, _stext).
> 4. __purge_vmap_area_lazy() depopulate the shadow (reserved pages),
> triggering the BUG.
>
> KASLR is not the root cause, but it increases the hit probability.
>   
> I was able to reproduce this issue on upstream kernel (Linux 6.17.0-
> rc7) with QEMU (version 5.2.0 (Debian 1:5.2+dfsg-9ubuntu3.3)).
> The key is to ensure we allocate the execmem into the [_text, _stext)
> hole and then trigger __purge_vmap_area_lazy().
>
> Reproduce the problem:
> 1. Temporarily hardcode execmem_arch_setup() to set module_direct_base
> =_text, so module allocations fall into the hole.
> 2. CONFIG_DEBUG_VM=y is also required to make the error report visible.
> 3. Then insmod & rmmod (any .ko file) will trigger the problem.
>
> I plan to send a patch to exclude [_text, _stext) from
> kasan_init_shadow(). In our testing, this fix the issue.

I think this has been fixed by this patch:
https://lore.kernel.org/linux-arm-kernel/93a6f8e47cce118493e250b719a927f517be12cf.1758316750.git.osandov@xxxxxxxxxxx/

Will already applied it to -next tree AFAIK.

Thanks,
Yang

> Thanks!
> Qun-wei
>
>
> [0]:https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/pi/map_kernel.c#L81
> [1]:https://github.com/torvalds/linux/blob/master/arch/arm64/mm/kasan_init.c#L309
>
>
>