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

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

[Qun-wei Lin (林群崴)]

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:
[    7.509660][T00400000001] init: init 6: Loading module
/lib/modules/panel-truly-nt35595-cmd.ko withargs ''
[    7.519549][T00400000079] kworker/4:1: BUG: Bad page state in
processkworker/4:1  pfn:37ddf4
[    7.520776][T00400000079] kworker/4:1: page: refcount:0 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x37ddf4
[    7.521470][T00200000001] init: init 6: Loaded kernel module
/lib/modules/panel-truly-nt35595-cmd.ko
[    7.522212][T00400000079] kworker/4:1: flags:
0x4000000000004000(reserved|zone=1)
[    7.523750][T00200000001] init: init 6: Loading module
/lib/modules/panel-alpha-jdi-nt36672e-vdo-60hz.ko withargs ''
[    7.524512][T00400000079] kworker/4:1: raw: 4000000000004000
fffffffecbf77d08fffffffecbf77d08 0000000000000000
[    7.527422][T00400000079] kworker/4:1: raw: 0000000000000000
0000000000000000 00000000ffffffff 0000000000000000
[    7.528845][T00400000079] kworker/4:1: page dumped because:
PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[    7.530066][T00400000079] kworker/4:1: page_owner info is not
present (never set?)
[    7.531117][T00400000079] kworker/4:1: Modules linked in:
panel_truly_nt35595_cmd(OE) panel_nt37801_cmd_spr(OE)
panel_nt37801_cmd_120hz(OE)
[    7.560646][T00400000079] kworker/4:1: CPU: 4 UID: 0 PID: 79
Comm:kworker/4:1 Tainted: G          OE      6.12.23-android16-5-
g1e57f0e5996f-4k #1 eee834a579887c0f97d696d30c786233f4fbfcdf
[    7.560662][T00400000079] kworker/4:1: Tainted: [O]=OOT_MODULE,
[E]=UNSIGNED_MODULE
[    7.560666][T00400000079] kworker/4:1: Hardware name: MT6993(ENG)
(DT)
[    7.560671][T00400000079] kworker/4:1: Workqueue: events
do_free_init
[    7.560696][T00400000079] kworker/4:1: Call trace:
[    7.560700][T00400000079] kworker/4:1: dump_backtrace+0xf8/0x174
[    7.560714][T00400000079] kworker/4:1: show_stack+0x18/0x24
[    7.560720][T00400000079] kworker/4:1: dump_stack_lvl+0x40/0x9c
[    7.560738][T00400000079] kworker/4:1: dump_stack+0x18/0x24
[    7.560747][T00400000079] kworker/4:1: bad_page+0x194/0x1d0
[    7.560763][T00400000079]
kworker/4:1: free_page_is_bad_report+0x128/0x1ac
[    7.560772][T00400000079] kworker/4:1: free_unref_page+0xb78/0xc70
[    7.560782][T00400000079] kworker/4:1: __free_pages+0xec/0x400
[    7.560790][T00400000079] kworker/4:1: free_pages+0x2c/0x38
[    7.560798][T00400000079]
kworker/4:1: kasan_depopulate_vmalloc_pte+0x90/0xf8
[    7.560809][T00400000079]
kworker/4:1: __apply_to_page_range+0x4a8/0x5bc
[    7.560828][T00400000079]
kworker/4:1: apply_to_existing_page_range+0x14/0x20
[    7.560836][T00400000079]
kworker/4:1: kasan_release_vmalloc+0xa0/0x118
[    7.560842][T00400000079] kworker/4:1: purge_vmap_node+0x1cc/0x76c
[    7.560849][T00400000079]
kworker/4:1: __purge_vmap_area_lazy+0x5b8/0x820
[    7.560856][T00400000079] kworker/4:1: _vm_unmap_aliases+0x71c/0x7f0
[    7.560862][T00400000079] kworker/4:1: vm_reset_perms+0x200/0x2d8
[    7.560867][T00400000079] kworker/4:1: vfree+0x3d0/0x464
[    7.560873][T00400000079] kworker/4:1: execmem_free+0x4c/0x80
[    7.560884][T00400000079] kworker/4:1: do_free_init+0xbc/0xe8
[    7.560889][T00400000079]
kworker/4:1: process_scheduled_works+0x640/0xf80
[    7.560900][T00400000079] kworker/4:1: worker_thread+0x980/0xd1c
[    7.560907][T00400000079] kworker/4:1: kthread+0x2bc/0x494
[    7.560914][T00400000079] kworker/4:1: ret_from_fork+0x10/0x20
[    7.560924][T00400000079] kworker/4:1: Disabling lock debugging due
to kernel taint
[    7.588464][T00400000079] kworker/4:1: Kernel panic - not
syncing:panic_on_taint set ...
[    7.589603][T00400000079] kworker/4:1: CPU: 4 UID: 0 PID: 79
Comm:kworker/4:1 Tainted: G   B      OE     6.12.23-android16-5-
g1e57f0e5996f-4k #1 eee834a579887c0f97d696d30c786233f4fbfcdf
[    7.591913][T00400000079] kworker/4:1: Tainted: [B]=BAD_PAGE,
[O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[    7.593137][T00400000079] kworker/4:1: Hardware name: MT6993(ENG)
(DT)
[    7.594039][T00400000079] kworker/4:1: Workqueue: events
do_free_init
[    7.594937][T00400000079] kworker/4:1: Call trace:
[    7.595598][T00400000079] kworker/4:1: dump_backtrace+0xf8/0x174
[    7.596437][T00400000079] kworker/4:1: show_stack+0x18/0x24
[    7.597226][T00400000079] kworker/4:1: dump_stack_lvl+0x40/0x9c
[    7.598059][T00400000079] kworker/4:1: dump_stack+0x18/0x24
[    7.598849][T00400000079] kworker/4:1: panic+0x228/0x568
[    7.599600][T00400000079] kworker/4:1: add_taint+0xc8/0xe0
[    7.600376][T00400000079] kworker/4:1: bad_page+0xbc/0x1d0
[    7.601158][T00400000079]
kworker/4:1: free_page_is_bad_report+0x128/0x1ac
[    7.602127][T00400000079] kworker/4:1: free_unref_page+0xb78/0xc70
[    7.602996][T00400000079] kworker/4:1: __free_pages+0xec/0x400
[    7.603815][T00400000079] kworker/4:1: free_pages+0x2c/0x38
[    7.604602][T00400000079]
kworker/4:1: kasan_depopulate_vmalloc_pte+0x90/0xf8
[    7.605605][T00400000079]
kworker/4:1: __apply_to_page_range+0x4a8/0x5bc
[    7.606545][T00400000079]
kworker/4:1: apply_to_existing_page_range+0x14/0x20
[    7.607546][T00400000079]
kworker/4:1: kasan_release_vmalloc+0xa0/0x118
[    7.608472][T00400000079] kworker/4:1: purge_vmap_node+0x1cc/0x76c
[    7.609341][T00400000079]
kworker/4:1: __purge_vmap_area_lazy+0x5b8/0x820
[    7.610292][T00400000079]
kworker/4:1: _vm_unmap_aliases+0x71c/000000079] kworker/4:1: CPU
features: 0x0000000,00000014,0613e92c,437e7607
[    7.622275][T00400000079] kworker/4:1: Memory Limit: none
[    7.674062][T00400000079] kworker/4:1: Kernel Offset: 0x1ce7200000
from 0xffffffc080000000
[    7.675208][T00400000079] kworker/4:1: PHYS_OFFSET: 0x80000000
 
If I disable KASLR, the issue does not occur.
 
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.
 



Best Regards,
 
 
林群崴 (Qun-wei Lin)
Qun-wei.Lin@mediatek.com

 

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

[Ada Couprie Diaz]

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@mediatek.com
Thanks in advance,
Best regards
Ada


[0]: 
https://android.googlesource.com/kernel/common/+/refs/tags/android16-6.12-2025-06_r5
[1]: https://github.com/linux-apfs/linux-apfs-rw/
[2]: 
https://packages.debian.org/search?keywords=-dkms&searchon=names&suite=trixie&section=all

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

[Qun-wei Lin (林群崴)]

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


 

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