From: sashiko-bot@kernel.org
To: "Cong Wang" <xiyou.wangcong@gmail.com>,
"Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>
Cc: "Song Shuai" <songshuaishuai@tinylab.org>,
"Björn Töpel" <bjorn@kernel.org>, "Han Gao" <gaohan@iscas.ac.cn>,
"Jinjie Ruan" <ruanjinjie@huawei.com>,
"Mike Rapoport" <rppt@kernel.org>,
"Baoquan He" <baoquan.he@linux.dev>,
"Guo Ren" <guoren@kernel.org>,
kexec@lists.infradead.org, "Cong Wang" <cwang@multikernel.io>
Subject: Re: [PATCH] riscv: kexec_file: Keep segments out of the new kernel's PMD padding
Date: Sat, 14 Nov 2026 03:58:49 +0000 [thread overview]
Message-ID: <sashiko-outbox-214131@kernel.org> (raw)
In-Reply-To: <20261114034901.107028-1-xiyou.wangcong@gmail.com>
Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [High] kexec_file: missing placement bounds checks in
kexec_alloc_contig() [1]
--
commit e91ae0bea9270620f64704189d1d94046334bdb0
Author: Cong Wang <cwang@multikernel.io>
riscv: kexec_file: Keep segments out of the new kernel's PMD padding
This commit aligns kbuf.buf_min in load_extra_segments() to PMD_SIZE so
extra kexec segments are not placed inside the new kernel's PMD padding.
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 26cd2a8bd0cd3..0d2d43a7dbfaa 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -251,7 +251,8 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
> char *modified_cmdline = NULL;
>
> kbuf.image = image;
> - kbuf.buf_min = kernel_start + kernel_len;
> + /* The new kernel reserves itself up to the next PMD boundary */
> + kbuf.buf_min = ALIGN(kernel_start + kernel_len, PMD_SIZE);
> kbuf.buf_max = PFN_PHYS(max_low_pfn);
>
> #ifdef CONFIG_CRASH_DUMP
[Severity: High]
This problem wasn't introduced by this patch, but can kexec_alloc_contig()
bypass kbuf.buf_min and kbuf.buf_max when allocating a CMA segment for a
non-crash kexec_file_load() [1]?
Unlike locate_mem_hole_top_down() and locate_mem_hole_bottom_up(), which
check kbuf->buf_min, kbuf->buf_max, and arch_check_excluded_range(),
kexec_alloc_contig() only checks kimage_is_destination_range() (and passes
the exclusive end mem + kbuf->memsz rather than mem + kbuf->memsz - 1):
kernel/kexec_file.c:kexec_alloc_contig() {
...
p = dma_alloc_from_contiguous(NULL, nr_pages, get_order(kbuf->buf_align), true);
if (!p)
return -ENOMEM;
...
mem = page_to_boot_pfn(p) << PAGE_SHIFT;
if (kimage_is_destination_range(kbuf->image, mem, mem + kbuf->memsz)) {
...
dma_release_from_contiguous(NULL, p, nr_pages);
return -EBUSY;
}
kbuf->mem = page_to_boot_pfn(p) << PAGE_SHIFT;
kbuf->cma = p;
...
}
When CMA is enabled, kexec_add_buffer() -> kexec_locate_mem_hole() ->
kexec_alloc_contig() can place the initrd, DTB, or purgatory below
kbuf.buf_min, Above kbuf.buf_max, or inside an architecture-excluded range,
causing the new kernel to fail to boot or crash on kexec.
[1] https://sashiko.dev/#/bug/linux-83c15bd9-0ce0-4413-9330-a4e797594079
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114034901.107028-1-xiyou.wangcong@gmail.com?part=1
prev parent reply other threads:[~2026-11-14 3:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 3:49 [PATCH] riscv: kexec_file: Keep segments out of the new kernel's PMD padding Cong Wang
2026-11-14 3:49 ` Cong Wang
2026-11-14 3:58 ` sashiko-bot [this message]
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=sashiko-outbox-214131@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=baoquan.he@linux.dev \
--cc=bjorn@kernel.org \
--cc=cwang@multikernel.io \
--cc=gaohan@iscas.ac.cn \
--cc=guoren@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=songshuaishuai@tinylab.org \
--cc=xiyou.wangcong@gmail.com \
/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.