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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Use-After-Free (UAF) in lockless memblock iteration during concurrent memory hotplug.
--

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

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

This commit aims to fix a race condition in prepare_elf_headers() between
the initial pass that counts system RAM ranges and the second pass that
populates them. It adds padding to the initial allocation and introduces
a boundary check to prevent out-of-bounds writes if a concurrent memory
hotplug event increases the number of memory regions.

> diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
> index 5584b798ba464..3c369124586e1 100644
> --- a/arch/loongarch/kernel/machine_kexec_file.c
> +++ b/arch/loongarch/kernel/machine_kexec_file.c

[ ... ]

> @@ -75,6 +76,11 @@ static 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) {
> +		if (unlikely(cmem->nr_ranges >= cmem->max_nr_ranges)) {
> +			ret = -EAGAIN;
> +			goto out;
> +		}
> +

[Severity: Critical]
This is a pre-existing issue, but does this lockless iteration over the
memblock array risk a use-after-free during concurrent memory hotplug
operations?

While the new boundary check successfully protects against index overruns
within the newly allocated cmem array, prepare_elf_headers() iterates over
the underlying memblock array using for_each_mem_range() without holding
the mem_hotplug_lock.

If a concurrent memory hotplug event invokes add_memory(), it can trigger
a reallocation of the memblock array, freeing the old regions array while it
is still actively being traversed:

mm/memblock.c:memblock_double_array()
        memcpy(new_array, type->regions, old_size);
        ...
        type->regions = new_array;
        ...
        if (*in_slab)
                kfree(old_array);

Would it be safer to acquire the hotplug lock (e.g., via get_online_mems())
before the lockless __next_mem_range() iterator attempts to dereference
potentially freed array pointers?

>  		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=14