Re: [PATCH v14 02/17] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing NULL check on `rmem` before accessing `rmem->nr_ranges` causes a NULL pointer dereference in `kexec_extra_fdt_size_ppc64()`.
- [Critical] `__merge_memory_ranges()` incorrectly shrinks overlapping memory ranges, causing critical memory regions to be lost.
--

commit 4efbfe4b6923f71ffba2342131a0178fa07349c0
Author: Jinjie Ruan <ruanjinjie@huawei.com>

powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()

This commit fixes a memory leak in update_crash_elfcorehdr() by ensuring
allocated memory from get_crash_memory_ranges() is freed if an error occurs.
It updates the code to jump to the out label to properly free the memory.

> diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
> index e6539f213b3d1..a520f851c3a6b 100644
> --- a/arch/powerpc/kexec/crash.c
> +++ b/arch/powerpc/kexec/crash.c
> @@ -502,7 +502,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
>  	ret = get_crash_memory_ranges(&cmem);
>  	if (ret) {
>  		pr_err("Failed to get crash mem range\n");
> -		return;
> +		goto out;
>  	}
>  
>  	/*

[Severity: Critical]
This is a pre-existing issue, but does kexec_extra_fdt_size_ppc64()
dereference a NULL pointer if rmem is NULL?

If get_reserved_memory_ranges(&rmem) returns 0 without allocating memory for
rmem (e.g., when there are no matching device tree nodes), rmem remains NULL
when passed to kexec_extra_fdt_size_ppc64():

arch/powerpc/kexec/elf_64.c:elf64_load() {
	...
	ret = get_reserved_memory_ranges(&rmem);
	if (ret)
		goto out;

	fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
					   initrd_len, cmdline,
					   kexec_extra_fdt_size_ppc64(image, rmem));
	...
}

Inside kexec_extra_fdt_size_ppc64(), there is no check before accessing
rmem->nr_ranges:

arch/powerpc/kexec/file_load_64.c:kexec_extra_fdt_size_ppc64() {
	...
	/* Consider extra space for reserved memory ranges if any */
	if (rmem->nr_ranges > 0)
		extra_size += (unsigned int)(rmem->nr_ranges * sizeof(u64));
	...
}

Could this lead to a NULL pointer dereference and a kernel panic during
the kexec device tree preparation?


[Severity: Critical]
This isn't a bug introduced by this patch, but does __merge_memory_ranges()
incorrectly shrink overlapping memory ranges?

When merging memory ranges, the code unconditionally assigns ranges[i].end
to ranges[idx].end without using max(), and compares the start against
ranges[i-1].end rather than ranges[idx].end:

arch/powerpc/kexec/ranges.c:__merge_memory_ranges() {
	...
	for (i = 1; i < mem_rngs->nr_ranges; i++) {
		if (ranges[i].start <= (ranges[i-1].end + 1))
			ranges[idx].end = ranges[i].end;
		else {
	...
}

If a smaller memory range is completely subsumed by a larger one, could this
assignment shrink the end boundary of the merged range?

Would this truncate valid memory blocks from the kexec exclude lists,
potentially allowing the new kernel to overwrite the running kernel's memory
and causing data corruption or crashes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525084932.934910-1-ruanjinjie@huawei.com?part=2