Re: [PATCH v3 09/11] arm64: 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] Pre-existing TOCTOU and heap buffer overflow in `prepare_elf_headers()` due to unlocked `memblock` traversal.
--

commit 4cfe0a8d3d6226820c437fa8c78ba7628ef98fd5
Author: Wandun Chen <chenwandun@lixiang.com>

arm64: kdump: exclude non-dumpable reserved memory regions from vmcore

This commit excludes device firmware memory regions reserved via device tree 
from the vmcore by default, honoring the dumpable flag. It calculates the 
required array size using of_reserved_mem_kdump_nr_ranges() and filters 
them via of_reserved_mem_kdump_exclude().

> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
[ ... ]
> @@ -51,6 +52,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 is a pre-existing issue, but could a concurrent memory hotplug event
cause a buffer overflow or use-after-free here?

The prepare_elf_headers() function iterates over memblock.memory locklessly
using for_each_mem_range() to count the memory ranges, and then allocates
the cmem array based on this count before later populating it.

Since ARM64 sets CONFIG_ARCH_KEEP_MEMBLOCK, memory hotplug operations can
dynamically add or remove regions at runtime via memblock_add_node() and
memblock_remove(). While these modifications are protected by
mem_hotplug_begin(), the sys_kexec_file_load() path does not appear to
acquire this lock.

If a hotplug event occurs between the counting loop and the population loop,
might the number of ranges increase and cause an out-of-bounds write past
the end of the allocated cmem->ranges array?

Additionally, can a concurrent hotplug trigger memblock_double_array(),
which reallocates the memblock.memory.regions array and frees the old one,
leading to a use-after-free read during the unlocked iteration?

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