Re: [PATCH v17 06/10] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Concurrent memory hotplug during kexec file load causes an out-of-bounds array write in `prepare_elf64_ram_headers_callback` due to a TOCTOU mismatch.
--

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

riscv: kexec_file: Use crash_prepare_headers() helper to simplify code

This commit refactors the crash core code to use crash_prepare_headers() to
reduce code duplication. It introduces arch_get_system_nr_ranges() to count
the max memory ranges and arch_crash_populate_cmem() to collect and fill
them into cmem.

> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 3f7766057cac3..439cbc50dfa69 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -44,6 +44,15 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> +unsigned int arch_get_system_nr_ranges(void)
> +{
> +	unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
> +
> +	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> +
> +	return nr_ranges;
> +}
> +
[ ... ]
> @@ -55,41 +64,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> -static int prepare_elf_headers(void **addr, unsigned long *sz)
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
>  {
> +	return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but is there a pre-existing race 
condition with concurrent memory hotplug here?

When kexec_file_load runs, arch_get_system_nr_ranges() counts the ranges to
allocate the cmem array in crash_prepare_headers(), and then
arch_crash_populate_cmem() fills it. Since this two-pass iteration is not
synchronized against memory hot-add events, could a new memory range be
added between the two passes?

If that happens, the number of discovered ranges will exceed the capacity
allocated for cmem. Looking at prepare_elf64_ram_headers_callback(), it
unconditionally writes to the array:

	cmem->ranges[cmem->nr_ranges].start = res->start;
	cmem->ranges[cmem->nr_ranges].end = res->end;
	cmem->nr_ranges++;

Could this result in an out-of-bounds write since it doesn't check against
cmem->max_nr_ranges during the second pass?

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