Message-ID: <cb9760e573d57072a28a45014f2c7938c083cdc2.camel@mediatek.com>
Date: Wed, 24 Sep 2025 12:41:09 +0000
From: Qun-wei Lin (林群崴) <Qun-wei.Lin@...iatek.com>
To: "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "ada.coupriediaz@....com"
	<ada.coupriediaz@....com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: Casper Li (李中榮) <casper.li@...iatek.com>,
	Andrew Yang (楊智強) <Andrew.Yang@...iatek.com>,
	Chinwen Chang (張錦文)
	<chinwen.chang@...iatek.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "andreyknvl@...gle.com" <andreyknvl@...gle.com>,
	"catalin.marinas@....com" <catalin.marinas@....com>, "dvyukov@...gle.com"
	<dvyukov@...gle.com>, "vincenzo.frascino@....com" <vincenzo.frascino@....com>
Subject: Re: [BUG] arm64: KASAN + KASLR may cause reserved page to be released
 during module loading

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@...iatek.com
> 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.


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


 

Powered by blists - more mailing lists