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

[sashiko-bot@kernel.org]

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

New issues:
- [High] Accessing freed `__initdata` array `reserved_mem_array` when `/reserved-memory` DT node is absent.

Pre-existing issues:
- [High] Out-of-bounds write in `prepare_elf64_ram_headers_callback` due to a Time-of-Check to Time-of-Use (TOCTOU) race condition with memory hotplug.
--

commit 4dec7cc9539d2fdcf926f6b807bb95730aa0a6b5
Author: Wandun Chen <chenwandun1@gmail.com>

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

This commit applies the same non-dumpable reserved memory filtering to
RISC-V kdump as was done for arm64. It uses of_reserved_mem_kdump_exclude()
to drop flagged regions from the elfcorehdr PT_LOAD segments, and
of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.

> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 54e2d9552e930..c359cf714c791 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
[ ... ]
> @@ -63,6 +64,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>  
>  	nr_ranges = 1; /* For exclusion of crashkernel region */
>  	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);

[Severity: High]
This isn't a bug introduced by this patch, but does this two-pass approach
with walk_system_ram_res() have a Time-of-Check to Time-of-Use (TOCTOU)
race condition with memory hotplug?

Because kexec_file_load does not hold the memory hotplug lock
(get_online_mems()), and memory hotplug operations (add_memory()) do not
block on kexec_mutex (they only try to acquire it in the memory notifier
crash_hotplug_handler, which logs and returns early on contention), a
concurrent memory hot-add can increase the number of RAM ranges between
the counting pass here and the later population pass.

Could this cause the second pass to execute the callback more times than
the allocated size, leading to an out-of-bounds write that corrupts the
heap?

> +	nr_ranges += of_reserved_mem_kdump_nr_ranges();
>  
>  	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>  	if (!cmem)
> @@ -76,6 +78,8 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>  
>  	/* Exclude crashkernel region */
>  	ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> +	if (!ret)
> +		ret = of_reserved_mem_kdump_exclude(cmem);

[Severity: High]
Can these kdump helpers access a freed __initdata array if the
/reserved-memory DT node is absent?

If a Device Tree contains /memreserve/ entries but lacks a
/reserved-memory node, fdt_scan_reserved_mem_late() returns early and
skips calling alloc_reserved_mem_array(). As a result, reserved_mem
continues to point to the statically allocated reserved_mem_array, which is
marked as __initdata and is freed by the kernel at the end of the boot
process.

The newly introduced fdt_reserved_mem_save_memreserve_entries() then
populates this __initdata array with /memreserve/ entries. When
kexec_file_load later calls these kdump helpers, could it read from the
freed __initdata array, resulting in a Use-After-Free?

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