Re: [PATCH v15 08/23] arm64: kexec_file: Fix image->elf_headers memory leak during retry loop

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Lockless traversal of configfs subsystem children list and unprotected read of `key_count` causes out-of-bounds writes and use-after-free.
--

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

arm64: kexec_file: Fix image->elf_headers memory leak during retry loop

This commit moves prepare_elf_headers() outside the retry loop in
image_load(). It prevents leaking memory allocated for image->elf_headers
on failure paths and reuses the pre-allocated header on retries.

> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 13c247c288660..4cbb71e1f8ed5 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
[ ... ]
> @@ -105,32 +105,19 @@ int load_other_segments(struct kimage *image,
>  	kbuf.buf_min = kernel_load_addr + kernel_size;
>  
>  #ifdef CONFIG_CRASH_DUMP
[ ... ]
> -		if (ret) {
> -			vfree(headers);
> +		if (ret)
>  			goto out_err;
> -		}
> -		image->elf_headers = headers;
>  		image->elf_load_addr = kbuf.mem;
> -		image->elf_headers_sz = headers_sz;
>  
>  		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
>  			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);

[Severity: High]
This is a pre-existing issue, but the crash dump setup here proceeds to call
crash_load_dm_crypt_keys(image) just below this block, which exposes a
potential race condition in the dm-crypt keys setup.

Is it safe for build_keys_header() in kernel/crash_dump_dm_crypt.c to
traverse config_keys_subsys.su_group.cg_children without holding the
subsystem mutex (config_keys_subsys.su_mutex)?

If a user concurrently adds a key via configfs:

kernel/crash_dump_dm_crypt.c:config_keys_make_item() {
    ...
    key_count++;
    ...
}

The lockless read of key_count to size the allocation:

kernel/crash_dump_dm_crypt.c:build_keys_header() {
    ...
    keys_header = kzalloc(get_keys_header_size(key_count), GFP_KERNEL);
    ...
}

could race with the key addition. This would mean the subsequent list
traversal:

    list_for_each_entry(item, &config_keys_subsys.su_group.cg_children, ci_entry) {

could process more items than the allocated space allows, causing an
out-of-bounds write to keys_header->keys[i]. It could also encounter
partially unlinked items during concurrent configfs directory removals,
leading to a use-after-free.

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