[PATCH] riscv: kexec_file: Keep segments out of the new kernel's PMD padding

[PATCH] riscv: kexec_file: Keep segments out of the new kernel's PMD padding

[Cong Wang]

From: Cong Wang <cwang@multikernel.io>

A 64-bit kernel with STRICT_KERNEL_RWX reserves itself up to the next
PMD boundary past _end in setup_bootmem(). load_extra_segments() only
keeps the other segments above kernel_start + kernel_len, which is the
unaligned _end of the new kernel, so they may be placed in that padding.

The segments are placed top-down, which normally keeps them far from
the kernel. A kdump kernel's segments are confined to the crashkernel
region though, and when it has little room to spare, the lowest of
them, the initrd and the device tree, end up in the padding. The kdump
kernel then finds its initrd in memory it reserved for itself, drops
it, and panics without a root file system:

  crashkernel reserved: 0x000000017be00000 - 0x000000017fe00000 (64 MB)
  Loaded kernel at 0x17be00000 bufsz=0x1c40600 memsz=0x1cb1000
  Loaded initrd at 0x17db58000
  ...
  Starting crashdump kernel...
  INITRD: 0x17db58000+0x022a4000 overlaps in-use memory region
  ...
  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The load itself succeeds, so this only shows once the system crashes.

The kernel being loaded may be any version or configuration that
reserves the padding, so the loader has to keep clear of it. Start the
other segments at the next PMD boundary. A crashkernel region too small
for them now fails the load with -EADDRNOTAVAIL, and one with enough
room boots the kdump kernel with its initrd.

This was found while testing multikernel, which loads a kernel with
kexec_file and hits the same overlap.

Fixes: 809a11eea8e8 ("riscv: kexec_file: Support loading Image binary file")
Signed-off-by: Cong Wang <cwang@multikernel.io>
---
 arch/riscv/kernel/machine_kexec_file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 26cd2a8bd0cd..0d2d43a7dbfa 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
-- 
2.43.0

Re: [PATCH] riscv: kexec_file: Keep segments out of the new kernel's PMD padding

[Ze Huang]

On Sat Nov 14, 2026 at 11:49 AM CST, Cong Wang wrote:
> From: Cong Wang <cwang@multikernel.io>
>
> A 64-bit kernel with STRICT_KERNEL_RWX reserves itself up to the next
> PMD boundary past _end in setup_bootmem(). load_extra_segments() only
> keeps the other segments above kernel_start + kernel_len, which is the
> unaligned _end of the new kernel, so they may be placed in that padding.
>
> The segments are placed top-down, which normally keeps them far from
> the kernel. A kdump kernel's segments are confined to the crashkernel
> region though, and when it has little room to spare, the lowest of
> them, the initrd and the device tree, end up in the padding. The kdump
> kernel then finds its initrd in memory it reserved for itself, drops
> it, and panics without a root file system:
>
>   crashkernel reserved: 0x000000017be00000 - 0x000000017fe00000 (64 MB)
>   Loaded kernel at 0x17be00000 bufsz=0x1c40600 memsz=0x1cb1000
>   Loaded initrd at 0x17db58000
>   ...
>   Starting crashdump kernel...
>   INITRD: 0x17db58000+0x022a4000 overlaps in-use memory region
>   ...
>   Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>
> The load itself succeeds, so this only shows once the system crashes.
>
> The kernel being loaded may be any version or configuration that
> reserves the padding, so the loader has to keep clear of it. Start the
> other segments at the next PMD boundary. A crashkernel region too small
> for them now fails the load with -EADDRNOTAVAIL, and one with enough
> room boots the kdump kernel with its initrd.
>
> This was found while testing multikernel, which loads a kernel with
> kexec_file and hits the same overlap.

This catches insufficient space at load time rather than accepting a
layout that overlaps the target kernel's PMD padding and fails at boot.

Tested on an OrangePi RV2 (SpacemiT K1), using zero-padded initrds to
exercise the following cases:

1. With sufficient space, the patched loader boots the capture kernel
   and runs its initramfs /init.
2. Without the patch, a tight crash reservation accepts an unsafe
   layout; the capture kernel reports the initrd overlap and panics.
3. With the patch, the same tight configuration fails at load time
   with EADDRNOTAVAIL.

Tested-by: Ze Huang <ze.huang@oss.qualcomm.com>
Reviewed-by: Ze Huang <ze.huang@oss.qualcomm.com>

>
> Fixes: 809a11eea8e8 ("riscv: kexec_file: Support loading Image binary file")
> Signed-off-by: Cong Wang <cwang@multikernel.io>
> ---
>  arch/riscv/kernel/machine_kexec_file.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 26cd2a8bd0cd..0d2d43a7dbfa 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