Re: [PATCH v2 8/8] 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.memory during kexec_file_load can race with memory hotplug, leading to Use-After-Free (UAF) and out-of-bounds writes.
--

commit 940dd878bcc6cf760efd15c48a5b87206c6b6d94
Author: Wandun Chen <chenwandun1@gmail.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 and
of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.

> diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
> index 5584b798ba464..c5cead362d2db 100644
> --- 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++;

[Severity: High]
This isn't a bug introduced by this patch, but can this lockless iteration
of memblock.memory race with memory hotplug?

The kexec_file_load syscall enters prepare_elf_headers() without holding
get_online_mems() or any lock that serializes against CPU/memory hotplug.

Inside prepare_elf_headers(), for_each_mem_range() locklessly iterates over
the memblock.memory regions twice: first to count the regions (nr_ranges),
and second to populate the cmem->ranges array.

On architectures that keep memblock post-boot (like LoongArch with
CONFIG_ARCH_KEEP_MEMBLOCK), a concurrent memory hotplug event
(e.g., add_memory_resource()) can mutate memblock.memory via
memblock_add_node().

If memblock.memory.cnt reaches its capacity, memblock_add_node() invokes
memblock_double_array(), which allocates a larger array, copies the
contents, and frees the old array. The concurrent for_each_mem_range() loop
could then access the freed array, resulting in a use-after-free.

Additionally, if memblock.memory.cnt increases between the first counting
loop and the second population loop, cmem->nr_ranges will exceed the
allocated size of the flex array, causing an out-of-bounds write into the
cmem->ranges array.

> +	nr_ranges += of_reserved_mem_kdump_nr_ranges();
>  
>  	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>  	if (!cmem)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520091844.592753-1-chenwandun@lixiang.com?part=8