Re: [PATCH v14 06/17] arm64: kexec_file: Fix potential buffer overflow in prepare_elf_headers()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] If kexec_add_buffer() fails for the ELF headers segment in load_other_segments(), it erroneously calls vfree(headers). However, the caller image_load() operates in a placement retry loop and will reuse the freed pointer on the next iteration, leading to a Use-After-Free. Furthermore, the global cleanup path will double-free the pointer.
- [High] In crash_load_dm_crypt_keys(), if kexec_add_buffer() fails, the global keys_header is freed via kvfree() but the pointer is not set to NULL. If the kexec load sequence retries, it will trigger a Use-After-Free or Double Free.
--

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

arm64: kexec_file: Fix potential buffer overflow in prepare_elf_headers()

This commit addresses a TOCTOU race condition in prepare_elf_headers() during
memory hotplug events by physically isolating the locking contexts. It moves
the get_online_mems() read lock to the top-level architecture image loaders
and adds bounds checking in machine_kexec_file.c.

> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 79efeaeb71e93..884e446f08e34 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c

[ ... ]

> @@ -96,11 +97,14 @@ static void *image_load(struct kimage *image,
>  
>  #ifdef CONFIG_CRASH_DUMP
>  	if (image->type == KEXEC_TYPE_CRASH) {
> +		get_online_mems();
>  		ret = prepare_elf_headers(&headers, &headers_sz);
>  		if (ret) {
>  			pr_err("Preparing elf core header failed\n");
> +			put_online_mems();
>  			return ERR_PTR(ret);
>  		}
> +		put_online_mems();
>  		image->elf_headers = headers;
>  		image->elf_headers_sz = headers_sz;
>  	}

[Severity: High]
This is a pre-existing issue, but does the retry loop directly below this
code lead to a use-after-free if kexec_add_buffer() fails in
load_other_segments()?

Looking at image_load(), the while loop attempts to load segments and calls
load_other_segments() repeatedly. If load_other_segments() fails during
kexec_add_buffer(), it calls vfree(headers). However, the loop in
image_load() will try again and pass the same freed headers pointer to
load_other_segments() on the next iteration.

Additionally, if the loop exhausts all options, does the global cleanup path
arch_kimage_file_post_load_cleanup() also unconditionally call
vfree(image->elf_headers), resulting in a double-free?

[Severity: High]
This is a pre-existing issue, but can this retry loop similarly trigger
a use-after-free or double-free with keys_header?

If kexec_add_buffer() fails inside crash_load_dm_crypt_keys(), the global
pointer keys_header is freed via kvfree() but not set to NULL.

When image_load() retries, crash_load_dm_crypt_keys() is invoked again. If it
calls build_keys_header(), it executes:

    if (keys_header != NULL)
        kvfree(keys_header);

which would trigger a double-free. Alternatively, if is_dm_key_reused is
true, would it reuse the freed pointer directly for a new
kexec_add_buffer() call?

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