Message-ID: <6ec322e5-f22f-4115-ae1e-e3ad0ee7d3ee@os.amperecomputing.com>
Date: Wed, 24 Sep 2025 11:18:46 -0700
From: Yang Shi <yang@...amperecomputing.com>
To: Qun-wei Lin (林群崴) <Qun-wei.Lin@...iatek.com>,
 "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>,
 Will Deacon <will@...nel.org>
Subject: Re: [BUG] arm64: KASAN + KASLR may cause reserved page to be released
 during module loading



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

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

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
>
>
>   

Powered by blists - more mailing lists