Re: [PATCH] kexec: Initialize ELF lowest address to ULONG_MAX

Hello Baoquan and Eric,


On 12/12/24 08:25, Baoquan he wrote:

On 12/10/24 at 02:43pm, Sourabh Jain wrote:

quoted

kexec_elf_load() loads an ELF executable and sets the address of the
lowest PT_LOAD section to the address held by the lowest_load_addr
function argument.

To determine the lowest PT_LOAD address, a local variable lowest_addr
(type unsigned long) is initialized to UINT_MAX. After loading each
PT_LOAD, its address is compared to lowest_addr. If a loaded PT_LOAD
address is lower, lowest_addr is updated. However, setting lowest_addr
to UINT_MAX won't work when the kernel image is loaded above 4G, as the
returned lowest PT_LOAD address would be invalid. This is resolved by
initializing lowest_addr to ULONG_MAX instead.

This issue was discovered while implementing crashkernel high/low
reservation on the PowerPC architecture.

Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()")
Cc: Baoquan he <redacted>
Cc: Hari Bathini <hbathini@linux.ibm.com>
CC: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: kexec@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sourabh Jain <redacted>
---
  kernel/kexec_elf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
index d3689632e8b9..3a5c25b2adc9 100644
--- a/kernel/kexec_elf.c
+++ b/kernel/kexec_elf.c

@@ -390,7 +390,7 @@ int kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,
  			 struct kexec_buf *kbuf,
  			 unsigned long *lowest_load_addr)
  {
-	unsigned long lowest_addr = UINT_MAX;
+	unsigned long lowest_addr = ULONG_MAX;

Great catch.

Acked-by: Baoquan He <redacted>

Thank you for the Ack! The upcoming two patch series, which aim to 
enable generic crashkernel reservation, depends on this fix. One of them 
is already posted for upstream review: 
https://lore.kernel.org/all/20250108101458.406806-1-sourabhjain@linux.ibm.com/ (local) 
I was wondering if you could guide us on how to get this fix pushed to 
the mainline tree.

Thanks,
Sourabh Jain