Re: [PATCH v13 03/15] x86/kexec: Fix potential buffer overflow in prepare_elf_headers()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Spurious -ENOMEM failure to userspace and false architectural assumption regarding hotplug correction (fixed later in series).
--

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

x86/kexec: Fix potential buffer overflow in prepare_elf_headers()

This commit adds a boundary check in prepare_elf64_ram_headers_callback()
to prevent a buffer overflow if memory hotplug increases the number of
memory regions between the counting and population passes.

> Since x86 supports crash hotplug, any data inconsistency caused by
> a race during the initial load will be corrected by the subsequent
> hotplug update. However, we must prevent a buffer overflow if the
> number of memory regions increases between the two passes.

Is this description of the hotplug update accurate?

The initial load syscall actively holds the atomic kexec_trylock() for its
entire duration. If a hotplug event occurs concurrently, wouldn't the
hotplug notifier (crash_handle_hotplug_event()) fail to acquire the lock,
log a lock failure, and permanently drop the update?

> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -225,6 +225,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  {
>  	struct crash_mem *cmem = arg;
>  
> +	if (cmem->nr_ranges >= cmem->max_nr_ranges)
> +		return -ENOMEM;
> +

Does returning -ENOMEM here abort the sys_kexec_file_load() syscall,
propagating a spurious error to userspace and leaving the system without a
loaded crash kernel?

Commit a0b7fe2dc98fe ("crash: Add crash_prepare_headers() to exclude crash
kernel memory") later in the series resolves this spurious error by adding
get_online_mems() to serialize the memory passes.

However, if the hotplug update is dropped due to the kexec_trylock()
contention mentioned above, and the race occurs in a way that does not
trigger this bounds check (such as memory regions decreasing), does the
kdump image still remain permanently out of sync with the actual memory
layout?

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