1. Patchew
  2. linux
  3. View series

[PATCH v2] kho: skip KHO for crash kernel

Evangelos Petrongonas posted 1 patch 2 months, 1 week ago 
kernel/liveupdate/kexec_handover.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH v2] kho: skip KHO for crash kernel
Posted by Evangelos Petrongonas 2 months, 1 week ago 
kho_fill_kimage() unconditionally populates the kimage with KHO
metadata for every kexec image type. When the image is a crash kernel,
this can be problematic as the crash kernel can run in a small reserved
region and the KHO scratch areas can sit outside it.
The crash kernel then faults during kho_memory_init() when it
tries phys_to_virt() on the KHO FDT address:

  Unable to handle kernel paging request at virtual address xxxxxxxx
  ...
    fdt_offset_ptr+...
    fdt_check_node_offset_+...
    fdt_first_property_offset+...
    fdt_get_property_namelen_+...
    fdt_getprop+...
    kho_memory_init+...
    mm_core_init+...
    start_kernel+...

kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
images, but kho_fill_kimage() was missing the same guard. As
kho_fill_kimage() is the single point that populates image->kho.fdt
and image->kho.scratch, fixing it here is sufficient for both arm64
and x86 as the FDT and boot_params path are bailing out when these
fields are unset.

Fixes: d7255959b69a ("kho: allow kexec load before KHO finalization")
Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
---

v2: Per Mike's review [1], move the guard into kho_fill_kimage() instead
    of patching the arch-level producers and consumers. This fixes
    both arm64 and x86 in one place and avoids redundant checks. Tested again.

Note regarding backporting
The offending commit was deployed with 6.19. The only other supported
kernel version with 6.18, unless I miss someting uses
```
if (!kho_out.finalized)
```
which in the case of crash kernel it shouldn't be finalised.


[1] https://lore.kernel.org/all/ade2ExpM8ROXV-vy@kernel.org/

 kernel/liveupdate/kexec_handover.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index cc68a3692905..1029fe8778f2 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1551,7 +1551,7 @@ int kho_fill_kimage(struct kimage *image)
 	int err = 0;
 	struct kexec_buf scratch;
 
-	if (!kho_enable)
+	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
 		return 0;
 
 	image->kho.fdt = virt_to_phys(kho_out.fdt);
-- 
2.47.3




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
Re: [PATCH v2] kho: skip KHO for crash kernel
Posted by Mike Rapoport 1 month, 3 weeks ago 
From: Mike Rapoport (Microsoft) <rppt@kernel.org>

On Fri, 10 Apr 2026 01:16:05 +0000, Evangelos Petrongonas wrote:
> kho_fill_kimage() unconditionally populates the kimage with KHO
> metadata for every kexec image type. When the image is a crash kernel,
> this can be problematic as the crash kernel can run in a small reserved
> region and the KHO scratch areas can sit outside it.
> The crash kernel then faults during kho_memory_init() when it
> tries phys_to_virt() on the KHO FDT address:
> 
> [...]

Applied to fixes branch of liveupdate/linux.git tree, thanks!

[1/1] kho: skip KHO for crash kernel
      commit: a6715d7ec472a476db17787697a4abda62962284

tree: https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux
branch: fixes

--
Sincerely yours,
Mike.
Re: [PATCH v2] kho: skip KHO for crash kernel
Posted by Pratyush Yadav 2 months, 1 week ago 
Hi Evangelos,

On Fri, Apr 10 2026, Evangelos Petrongonas wrote:

> kho_fill_kimage() unconditionally populates the kimage with KHO
> metadata for every kexec image type. When the image is a crash kernel,
> this can be problematic as the crash kernel can run in a small reserved
> region and the KHO scratch areas can sit outside it.
> The crash kernel then faults during kho_memory_init() when it
> tries phys_to_virt() on the KHO FDT address:
>
>   Unable to handle kernel paging request at virtual address xxxxxxxx
>   ...
>     fdt_offset_ptr+...
>     fdt_check_node_offset_+...
>     fdt_first_property_offset+...
>     fdt_get_property_namelen_+...
>     fdt_getprop+...
>     kho_memory_init+...
>     mm_core_init+...
>     start_kernel+...
>
> kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
> images, but kho_fill_kimage() was missing the same guard. As
> kho_fill_kimage() is the single point that populates image->kho.fdt
> and image->kho.scratch, fixing it here is sufficient for both arm64
> and x86 as the FDT and boot_params path are bailing out when these
> fields are unset.
>
> Fixes: d7255959b69a ("kho: allow kexec load before KHO finalization")
> Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> ---
>
> v2: Per Mike's review [1], move the guard into kho_fill_kimage() instead
>     of patching the arch-level producers and consumers. This fixes
>     both arm64 and x86 in one place and avoids redundant checks. Tested again.
>
> Note regarding backporting
> The offending commit was deployed with 6.19. The only other supported
> kernel version with 6.18, unless I miss someting uses
> ```
> if (!kho_out.finalized)
> ```
> which in the case of crash kernel it shouldn't be finalised.

While normally you should load the crash kernel early in boot and at
that point KHO should not be finalized, I don't see anything that
prevents crash kernel from being loaded after finalize. In which case,
you can trigger this bug before d7255959b69a ("kho: allow kexec load
before KHO finalization") as well. Also, before f322a97aeb2a ("kho: only
fill kimage if KHO is finalized") (landed in v6.18) kho_fill_kimage()
was also guarded by if (!kho_enable). So you'd hit this bug in all
kernels before that point in the very same way as today.

So should we update Fixes to 3bdecc3c93f9 ("kexec: add KHO support to
kexec file loads") and Cc stable?

>
> [1] https://lore.kernel.org/all/ade2ExpM8ROXV-vy@kernel.org/
>
>  kernel/liveupdate/kexec_handover.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index cc68a3692905..1029fe8778f2 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -1551,7 +1551,7 @@ int kho_fill_kimage(struct kimage *image)
>  	int err = 0;
>  	struct kexec_buf scratch;
>  
> -	if (!kho_enable)
> +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
>  		return 0;
>  
>  	image->kho.fdt = virt_to_phys(kho_out.fdt);

-- 
Regards,
Pratyush Yadav
Re: [PATCH v2] kho: skip KHO for crash kernel
Posted by Evangelos Petrongonas 2 months ago 
On Mon, Apr 13, 2026 at 01:52:40PM +0000 Pratyush Yadav wrote:
> Hi Evangelos,
> 
> On Fri, Apr 10 2026, Evangelos Petrongonas wrote:
> 
> > kho_fill_kimage() unconditionally populates the kimage with KHO
> > metadata for every kexec image type. When the image is a crash kernel,
> > this can be problematic as the crash kernel can run in a small reserved
> > region and the KHO scratch areas can sit outside it.
> > The crash kernel then faults during kho_memory_init() when it
> > tries phys_to_virt() on the KHO FDT address:
> >
> >   Unable to handle kernel paging request at virtual address xxxxxxxx
> >   ...
> >     fdt_offset_ptr+...
> >     fdt_check_node_offset_+...
> >     fdt_first_property_offset+...
> >     fdt_get_property_namelen_+...
> >     fdt_getprop+...
> >     kho_memory_init+...
> >     mm_core_init+...
> >     start_kernel+...
> >
> > kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
> > images, but kho_fill_kimage() was missing the same guard. As
> > kho_fill_kimage() is the single point that populates image->kho.fdt
> > and image->kho.scratch, fixing it here is sufficient for both arm64
> > and x86 as the FDT and boot_params path are bailing out when these
> > fields are unset.
> >
> > Fixes: d7255959b69a ("kho: allow kexec load before KHO finalization")
> > Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> > ---
> >
> > v2: Per Mike's review [1], move the guard into kho_fill_kimage() instead
> >     of patching the arch-level producers and consumers. This fixes
> >     both arm64 and x86 in one place and avoids redundant checks. Tested again.
> >
> > Note regarding backporting
> > The offending commit was deployed with 6.19. The only other supported
> > kernel version with 6.18, unless I miss someting uses
> > ```
> > if (!kho_out.finalized)
> > ```
> > which in the case of crash kernel it shouldn't be finalised.
> 
> While normally you should load the crash kernel early in boot and at
> that point KHO should not be finalized, I don't see anything that
> prevents crash kernel from being loaded after finalize. In which case,
> you can trigger this bug before d7255959b69a ("kho: allow kexec load
> before KHO finalization") as well. Also, before f322a97aeb2a ("kho: only
> fill kimage if KHO is finalized") (landed in v6.18) kho_fill_kimage()
> was also guarded by if (!kho_enable). So you'd hit this bug in all
> kernels before that point in the very same way as today.
> 
> So should we update Fixes to 3bdecc3c93f9 ("kexec: add KHO support to
> kexec file loads") and Cc stable?
> 
But in this case it seems a userspace misuse if it finalizes kho for
crash kernel. Whereas with the current state we hit the bug with a sane
userspace. Yeap we would hit that in earlier kernel than 6.18, but none
with KHO is supported is it?

I don't have strong objection for backporting it to 6.18, but it feels
unnecessary. 
> >
> > [1] https://lore.kernel.org/all/ade2ExpM8ROXV-vy@kernel.org/
> >
> >  kernel/liveupdate/kexec_handover.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> > index cc68a3692905..1029fe8778f2 100644
> > --- a/kernel/liveupdate/kexec_handover.c
> > +++ b/kernel/liveupdate/kexec_handover.c
> > @@ -1551,7 +1551,7 @@ int kho_fill_kimage(struct kimage *image)
> >  	int err = 0;
> >  	struct kexec_buf scratch;
> >  
> > -	if (!kho_enable)
> > +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
> >  		return 0;
> >  
> >  	image->kho.fdt = virt_to_phys(kho_out.fdt);
> 
> -- 
> Regards,
> Pratyush Yadav

Kind Regards,
Evangelos



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
Re: [PATCH v2] kho: skip KHO for crash kernel
Posted by Pratyush Yadav 2 months ago 
On Thu, Apr 16 2026, Evangelos Petrongonas wrote:

> On Mon, Apr 13, 2026 at 01:52:40PM +0000 Pratyush Yadav wrote:
>> Hi Evangelos,
>> 
>> On Fri, Apr 10 2026, Evangelos Petrongonas wrote:
[...]
>> > Note regarding backporting
>> > The offending commit was deployed with 6.19. The only other supported
>> > kernel version with 6.18, unless I miss someting uses
>> > ```
>> > if (!kho_out.finalized)
>> > ```
>> > which in the case of crash kernel it shouldn't be finalised.
>> 
>> While normally you should load the crash kernel early in boot and at
>> that point KHO should not be finalized, I don't see anything that
>> prevents crash kernel from being loaded after finalize. In which case,
>> you can trigger this bug before d7255959b69a ("kho: allow kexec load
>> before KHO finalization") as well. Also, before f322a97aeb2a ("kho: only
>> fill kimage if KHO is finalized") (landed in v6.18) kho_fill_kimage()
>> was also guarded by if (!kho_enable). So you'd hit this bug in all
>> kernels before that point in the very same way as today.
>> 
>> So should we update Fixes to 3bdecc3c93f9 ("kexec: add KHO support to
>> kexec file loads") and Cc stable?
>> 
> But in this case it seems a userspace misuse if it finalizes kho for
> crash kernel. Whereas with the current state we hit the bug with a sane
> userspace. Yeap we would hit that in earlier kernel than 6.18, but none
> with KHO is supported is it?
>
> I don't have strong objection for backporting it to 6.18, but it feels
> unnecessary. 

Fair enough. Let's leave it as it is then.

[...]

-- 
Regards,
Pratyush Yadav
Re: [PATCH v2] kho: skip KHO for crash kernel
Posted by Mike Rapoport 2 months, 1 week ago 
On Fri, Apr 10, 2026 at 01:16:05AM +0000, Evangelos Petrongonas wrote:
> kho_fill_kimage() unconditionally populates the kimage with KHO
> metadata for every kexec image type. When the image is a crash kernel,
> this can be problematic as the crash kernel can run in a small reserved
> region and the KHO scratch areas can sit outside it.
> The crash kernel then faults during kho_memory_init() when it
> tries phys_to_virt() on the KHO FDT address:
> 
>   Unable to handle kernel paging request at virtual address xxxxxxxx
>   ...
>     fdt_offset_ptr+...
>     fdt_check_node_offset_+...
>     fdt_first_property_offset+...
>     fdt_get_property_namelen_+...
>     fdt_getprop+...
>     kho_memory_init+...
>     mm_core_init+...
>     start_kernel+...
> 
> kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
> images, but kho_fill_kimage() was missing the same guard. As
> kho_fill_kimage() is the single point that populates image->kho.fdt
> and image->kho.scratch, fixing it here is sufficient for both arm64
> and x86 as the FDT and boot_params path are bailing out when these
> fields are unset.
> 
> Fixes: d7255959b69a ("kho: allow kexec load before KHO finalization")
> Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> v2: Per Mike's review [1], move the guard into kho_fill_kimage() instead
>     of patching the arch-level producers and consumers. This fixes
>     both arm64 and x86 in one place and avoids redundant checks. Tested again.
> 
> Note regarding backporting
> The offending commit was deployed with 6.19. The only other supported
> kernel version with 6.18, unless I miss someting uses
> ```
> if (!kho_out.finalized)
> ```
> which in the case of crash kernel it shouldn't be finalised.

Yes, this seems about right :) 
The only released kernel that has this issue is v6.19 and it will be EOL in
less than a week.
 
> [1] https://lore.kernel.org/all/ade2ExpM8ROXV-vy@kernel.org/
> 
>  kernel/liveupdate/kexec_handover.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index cc68a3692905..1029fe8778f2 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -1551,7 +1551,7 @@ int kho_fill_kimage(struct kimage *image)
>  	int err = 0;
>  	struct kexec_buf scratch;
>  
> -	if (!kho_enable)
> +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
>  		return 0;
>  
>  	image->kho.fdt = virt_to_phys(kho_out.fdt);
> -- 
> 2.47.3
> 
> 
> 
> 
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
> 

-- 
Sincerely yours,
Mike.

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.