Re: [PATCH 1/2] s390/ipl: Fix NULL deref in kdump without re-IPL parm block

On Thu, Aug 13, 2026 at 11:19:27AM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] NULL pointer dereference in `dump_reipl_run()` when the system is booted without an IPL parameter block.
> - [High] Unbounded `memcpy()` in `reipl_type_init()` causes a heap buffer overflow in the dump kernel.
> --

...

> [Severity: High]
> This is a pre-existing issue, but looking at dump_reipl_run(), if the system
> boots without an IPL parameter block and sets reipl_block_actual to NULL,
> won't this unconditionally dereference it?

That's fixed in patch 2 of the series

> [Severity: High]
> This isn't a bug introduced by this patch, but looking at reipl_type_init(),
> could an untrusted size from the crashed kernel memory overflow the
> PAGE_SIZE buffers here?
> 
> arch/s390/kernel/ipl.c:reipl_type_init() {
>     ...
> 	reipl_block = os_info_old_entry(OS_INFO_REIPL_BLOCK, &size);
> 	if (!reipl_block)
> 		goto out;
> 	/*
> 	 * If we have an OS info reipl block, this will be used
> 	 */
> 	if (reipl_block->pb0_hdr.pbt == IPL_PBT_FCP) {
> 		memcpy(reipl_block_fcp, reipl_block, size);
> 		reipl_type = IPL_TYPE_FCP;
> 	} else if (reipl_block->pb0_hdr.pbt == IPL_PBT_NVME) {
>     ...
> }
> 
> If a malicious primary kernel crafts an os_info payload with a valid
> checksum but a size greater than PAGE_SIZE, wouldn't this cause a heap
> buffer overflow in the dump kernel, preventing the crash dump from being
> collected?

The primary kernel is not an untrusted security boundary for kdump. It
loads the dump kernel and can modify both the dump kernel image and the
data. A malicious primary kernel can therefore already prevent dump
collection or execute arbitrary code in the dump kernel. So, this
finding is outside the kernel threat model.