Re: [PATCH v15 12/23] arm64: kexec_file: Fix TOCTOU buffer overflow via memory region padding

[sashiko-bot@kernel.org]

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

New issues:
- [High] The newly added bounds check allows the loop to consume slots explicitly reserved for post-loop crashkernel exclusions, leading to an -ENOMEM failure instead of the intended -EAGAIN retry.

Pre-existing issues:
- [Critical] Lockless traversal of memblock regions using `for_each_mem_range()` without holding memory hotplug locks leaves a pre-existing Use-After-Free (UAF) vulnerability unmitigated.
--

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

arm64: kexec_file: Fix TOCTOU buffer overflow via memory region padding

Sashiko AI code review pointed out there is a TOCTOU (Time-of-Check to
Time-of-Use) race condition in prepare_elf_headers() between the initial
pass that counts System RAM ranges and the second pass that populates them.
If a memory hotplug event occurs between these two steps, the number of
memory regions may increase, causing an out-of-bounds write to
the cmem->ranges[] array.

> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 4cbb71e1f8ed5..8a96fb68b88d6 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -48,7 +48,8 @@ int prepare_elf_headers(void **addr, unsigned long *sz)
>  	u64 i;
>  	phys_addr_t start, end;
>  
> -	nr_ranges = 2; /* for exclusion of crashkernel region */
> +	/* for exclusion of crashkernel region */
> +	nr_ranges = 2 + CRASH_HOTPLUG_SAFETY_PADDING;
>  	for_each_mem_range(i, &start, &end)
>  		nr_ranges++;
>  
> @@ -59,6 +60,11 @@ int prepare_elf_headers(void **addr, unsigned long *sz)
>  	cmem->max_nr_ranges = nr_ranges;
>  	cmem->nr_ranges = 0;
>  	for_each_mem_range(i, &start, &end) {
        ^^^^^^^^^^^^^^^^^^

[Severity: Critical]
This is a pre-existing issue, but does locklessly traversing memblock regions
here leave a use-after-free window during concurrent memory hotplug?

Since this path only holds kexec_mutex and not get_online_mems(), concurrent
memory hotplug events like add_memory() can trigger memblock_add().

If the memblock regions array is full, memblock_double_array() will allocate
a new array and free the old one by calling kfree(old_array).

Could this concurrent free cause the internal memblock traversal logic in
__next_mem_range() to dereference a freed type->regions pointer?

> +		if (unlikely(cmem->nr_ranges >= cmem->max_nr_ranges)) {
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this bounds check allow memory hotplug region expansion to consume the
slots explicitly reserved for crashkernel exclusion?

Because nr_ranges initially reserved 2 slots for exclusion, if hotplug
expands the regions and consumes those slots, this check won't fail because
we haven't hit cmem->max_nr_ranges yet.

If the loop completes having consumed these reserved slots, subsequent calls
to crash_exclude_mem_range() will hit their internal limit:

    if (mem->nr_ranges == mem->max_nr_ranges)
        return -ENOMEM;

This returns -ENOMEM instead of the intended -EAGAIN retry, which aborts the
kexec load entirely.

Should this evaluate against cmem->max_nr_ranges - 2?

> +			ret = -EAGAIN;
> +			goto out;
> +		}
> +
>  		cmem->ranges[cmem->nr_ranges].start = start;
>  		cmem->ranges[cmem->nr_ranges].end = end - 1;
>  		cmem->nr_ranges++;

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