Re: [PATCH v2 6/8] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore

[Wandun <chenwandun1@gmail.com>]

On 5/20/26 20:02, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Lockless traversal of `memblock.memory` combined with a Time-of-Check to Time-of-Use (TOCTOU) pattern can cause an out-of-bounds array write if memory hotplug runs concurrently.
> --
>
> commit 9b53a1de1ee9b0da26c3c33056f291e1bba1171e
> Author: Wandun Chen <chenwandun1@gmail.com>
>
> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
>
> Reserved memory regions are excluded from vmcore by default unless marked
> dumpable. This patch honors the dumpable flag to filter out device firmware
> regions reserved via device tree to reduce vmcore size.
>
>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>> index e31fabed378a5..1d65320c6ba48 100644
>> --- 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++;
> [Severity: High]
> This is a pre-existing issue, but can this lockless traversal of
> memblock.memory result in an out-of-bounds write if memory hotplug runs
> concurrently?
>
> The prepare_elf_headers() function iterates over memblock.memory twice:
> first here to count the regions for sizing the cmem allocation, and then
> later to populate cmem->ranges. This runs during the kexec_file_load
> syscall which holds kexec_mutex but not memory hotplug locks like
> device_hotplug_lock.
>
> If a memory hotplug operation (e.g., via sysfs) occurs between the two
> loops, memblock_add_node() could resize memblock.memory.regions via
> memblock_double_array(). This would free the old array and increase the
> region count.
>
> Could this cause the second loop to iterate over a freed array and write
> past the end of the allocated cmem->ranges array?
IIUC, this is a real race: prepare_elf_headers() scans memblock.memory
twice without holding any memory hotplug lock so a concurrent hotplug
could increase memblock.memory.regions between the two loops and cause
an out-of-bounds write to cmem->ranges, and also a potentially UAF on
the old regions array if memblock_double_array() fires.

However, this issue is independent of the current patch, I'd prefer to
address the memblock/hotplug race in a separate patchset after I look
into it more carefully.
>
>> +	nr_ranges += of_reserved_mem_kdump_nr_ranges();
>>   
>>   	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>>   	if (!cmem)