Re: [PATCH v17 10/10] riscv: kexec_file: Add support for crashkernel CMA reservation

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing bounds check in `prepare_elf64_ram_headers_callback` can lead to an out-of-bounds heap write if memory is hot-plugged concurrently.
--

commit 12b2d1ca4895e26a575347f3f6f5b7e59957f99a
Author: Jinjie Ruan <ruanjinjie@huawei.com>

riscv: kexec_file: Add support for crashkernel CMA reservation

This commit adds CMA support for kdump crashkernel reservation on RISC-V.
It parses CMA reservation parameters, allocates the memory dynamically, and
handles exclusion of these ranges from the crash kernel memory appropriately.

> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 439cbc50dfa69..85f14abceb507 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -46,7 +46,7 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
>  
>  unsigned int arch_get_system_nr_ranges(void)
>  {
> -	unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
> +	unsigned int nr_ranges = 2 + crashk_cma_cnt; /* For exclusion of crashkernel region */

[Severity: High]
This is a pre-existing issue, but while modifying arch_get_system_nr_ranges(),
I noticed a potential race condition with concurrent memory hotplug.

In crash_prepare_headers(), the code counts the ranges and then allocates the
cmem array based on that count:

kernel/crash_core.c:crash_prepare_headers() {
    ...
    max_nr_ranges = arch_get_system_nr_ranges();
    if (!max_nr_ranges)
        return -ENOMEM;

    cmem = alloc_cmem(max_nr_ranges);
    if (!cmem)
        return -ENOMEM;

    ret = arch_crash_populate_cmem(cmem);
    ...
}

Neither kexec_lock nor resource_lock appears to be held to prevent the system
RAM resource tree from being modified between the counting phase and the
population phase. If a memory hotplug event inserts a new memory range during
this window, the second traversal of the resource tree will encounter it.

When that happens, could prepare_elf64_ram_headers_callback() write past the
end of the allocated cmem array?

arch/riscv/kernel/machine_kexec_file.c:prepare_elf64_ram_headers_callback() {
    ...
    cmem->ranges[cmem->nr_ranges].start = res->start;
    cmem->ranges[cmem->nr_ranges].end = res->end;
    cmem->nr_ranges++;
    ...
}

Does this callback need a bounds check against cmem->max_nr_ranges to prevent
an out-of-bounds heap write?

>  
>  	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629094746.191843-1-ruanjinjie@huawei.com?part=10