From: sashiko-bot@kernel.org
To: "Jinjie Ruan" <ruanjinjie@huawei.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org
Subject: Re: [PATCH v13 04/15] arm64: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
Date: Tue, 12 May 2026 00:45:33 +0000 [thread overview]
Message-ID: <20260512004533.B4863C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511030454.1730881-5-ruanjinjie@huawei.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Memory leak of image->elf_headers on error paths in load_other_segments().
--
commit 176ac9ad5382c8a7611ce5e111bc472c392e772b
Author: Jinjie Ruan <ruanjinjie@huawei.com>
arm64: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
This commit fixes a race condition between the kexec_load() system call and
memory hotplug operations that can lead to a buffer overflow. It adds an
explicit bounds check to prevent out-of-bounds access when populating
the memory ranges array.
Closes: https://sashiko.dev/#/patchset/20260323072745.2481719-1-ruanjinjie%40huawei.com
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index fba260ad87a96..df52ac4474c96 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -59,6 +59,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 (cmem->nr_ranges >= cmem->max_nr_ranges) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> cmem->ranges[cmem->nr_ranges].start = start;
> cmem->ranges[cmem->nr_ranges].end = end - 1;
> cmem->nr_ranges++;
While reviewing this commit, I noticed a pre-existing issue in the
surrounding code.
Could the error paths in load_other_segments() leak the memory
allocated by prepare_elf_headers()?
If a failure occurs later in load_other_segments(), for example when
adding the initrd or dtb, the function jumps to out_err:
arch/arm64/kernel/machine_kexec_file.c:load_other_segments() {
[ ... ]
ret = kexec_add_buffer(&kbuf);
if (ret) {
vfree(headers);
goto out_err;
}
image->elf_headers = headers;
[ ... ]
if (initrd) {
[ ... ]
ret = kexec_add_buffer(&kbuf);
if (ret)
goto out_err;
[ ... ]
out_err:
image->nr_segments = orig_segments;
kvfree(dtb);
return ret;
}
The out_err path returns an error but does not free image->elf_headers.
This seems problematic because the caller in kexec_image.c
handles placement failures by erasing the segment and retrying in a loop:
arch/arm64/kernel/kexec_image.c:image_load() {
[ ... ]
while ((ret = kexec_add_buffer(&kbuf)) == 0) {
kernel_segment = &image->segment[kernel_segment_number];
ret = load_other_segments(image, kernel_segment->mem, ...);
if (!ret)
break;
[ ... ]
}
Does this retry loop unconditionally allocate new ELF headers on each
iteration and permanently leak the previously allocated buffers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511030454.1730881-1-ruanjinjie@huawei.com?part=4
next prev parent reply other threads:[~2026-05-12 0:45 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 3:04 [PATCH v13 00/15] arm64/riscv: Add support for crashkernel CMA reservation Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 01/15] riscv: kexec_file: Fix crashk_low_res not exclude bug Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 02/15] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr() Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 03/15] x86/kexec: Fix potential buffer overflow in prepare_elf_headers() Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-12 0:18 ` sashiko-bot
2026-05-11 3:04 ` [PATCH v13 04/15] arm64: kexec_file: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 9:46 ` Breno Leitao
2026-05-11 9:46 ` Breno Leitao
2026-05-11 11:30 ` Jinjie Ruan
2026-05-11 11:30 ` Jinjie Ruan
2026-05-11 12:30 ` Breno Leitao
2026-05-11 12:30 ` Breno Leitao
2026-05-19 12:42 ` Jinjie Ruan
2026-05-19 12:42 ` Jinjie Ruan
2026-05-12 0:45 ` sashiko-bot [this message]
2026-05-19 12:33 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 05/15] riscv: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 06/15] LoongArch: kexec: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 07/15] powerpc/crash: sort crash memory ranges before preparing elfcorehdr Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 08/15] crash: Add crash_prepare_headers() to exclude crash kernel memory Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-12 4:23 ` sashiko-bot
2026-05-11 3:04 ` [PATCH v13 09/15] arm64: kexec_file: Use crash_prepare_headers() helper to simplify code Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 10/15] x86/kexec: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-12 5:48 ` sashiko-bot
2026-05-11 3:04 ` [PATCH v13 11/15] riscv: kexec_file: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 12/15] LoongArch: kexec: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 13/15] crash: Use crash_exclude_core_ranges() on powerpc Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 14/15] arm64: kexec: Add support for crashkernel CMA reservation Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
2026-05-11 3:04 ` [PATCH v13 15/15] riscv: " Jinjie Ruan
2026-05-11 3:04 ` Jinjie Ruan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260512004533.B4863C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=robh@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.