Re: [PATCH v3 11/11] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Lockless iteration of memblock regions causes a Time-of-Check to Time-of-Use (TOCTOU) heap buffer overflow and Use-After-Free.
--

commit b3c21375f26da6475c1a19c55f8aa3b310aa8539
Author: Wandun Chen <chenwandun@lixiang.com>
loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore

This commit applies non-dumpable reserved memory filtering to LoongArch kdump.
It uses of_reserved_mem_kdump_exclude() to drop flagged regions from the
elfcorehdr PT_LOAD segments and sizes the crash_mem array accordingly.

> diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
> --- a/arch/loongarch/kernel/machine_kexec_file.c
> +++ b/arch/loongarch/kernel/machine_kexec_file.c
[ ... ]
> @@ -67,6 +68,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>  	nr_ranges = 2; /* for exclusion of crashkernel region */
>  	for_each_mem_range(i, &start, &end)
>  		nr_ranges++;
> +	nr_ranges += of_reserved_mem_kdump_nr_ranges();
>  
>  	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for a concurrent
memory hotplug operation to cause a use-after-free or buffer overflow here?

Since prepare_elf_headers() executes in process context during the
kexec_file_load syscall, it iterates over memblock.memory via
for_each_mem_range() without holding get_online_mems() or other memory
hotplug locks.

On LoongArch, CONFIG_ARCH_KEEP_MEMBLOCK is enabled, meaning memblock is not
discarded after boot. Concurrent memory hotplug operations can invoke
add_memory_resource(), which calls memblock_add_node() and subsequently
memblock_double_array(). Since slab_is_available() is true at runtime, this
allocates a new array and calls kfree() on the old memblock.memory.regions
array, which could lead to a use-after-free during the lockless iteration.

Additionally, is there a time-of-check to time-of-use race?

The first loop locklessly counts regions to size the cmem array. If memory is
hotplugged between the counting loop and the second population loop, the
second loop will iterate more times than the allocated size.

Without bounds checks before adding entries to cmem->ranges, could this
overflow the kernel heap buffer?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527032917.3385849-1-chenwandun1@gmail.com?part=11