[PATCH 0/2] s390/ipl: Fix missing re-IPL parm blocks handling in dump paths

[PATCH 0/2] s390/ipl: Fix missing re-IPL parm blocks handling in dump paths

[Vasily Gorbik]

HMC FTP boot and QEMU direct kernel boot do not provide an IPL parameter
block. This can lead to NULL pointer dereferences during kdump and
stand-alone dump processing.

Fix the kdump and stand-alone dump paths separately. kdump continues
without a re-IPL parameter block, while the stand-alone dumper completes
the dump and halts.

Vasily Gorbik (2):
  s390/ipl: Fix NULL deref in kdump without re-IPL parm block
  s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block

 arch/s390/kernel/ipl.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

-- 
2.53.0

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

[Vasily Gorbik]

Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might
not provide an IPL parameter block. In this case, reipl_type_init()
selects IPL_TYPE_UNKNOWN, and reipl_block_actual remains NULL.

kdump passes the re-IPL parameter block to the dump kernel through
os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl
block checksum calculation"), the os_info entry was added only for
IPL types which initialized reipl_block_actual. That commit moved the
os_info update to machine_crash_shutdown(), making it unconditional. As
a result, set_os_info_reipl_block() dereferences reipl_block_actual for
IPL_TYPE_UNKNOWN. This may happen to work by chance when address zero
contains readable lowcore data and the resulting empty os_info entry is
ignored by the dump kernel.

Skip the os_info update when no re-IPL parameter block is available.
Kdump then collect the dump and reboot without setting re-IPL parameter
block.

Fixes: 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation")
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
---
 arch/s390/kernel/ipl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index 3c346b02ceb9..7024fc413715 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -1157,6 +1157,8 @@ static struct attribute_group reipl_nss_attr_group = {
 
 void set_os_info_reipl_block(void)
 {
+	if (!reipl_block_actual)
+		return;
 	os_info_entry_add_data(OS_INFO_REIPL_BLOCK, reipl_block_actual,
 			       reipl_block_actual->hdr.len);
 }
-- 
2.53.0

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

[Vasily Gorbik]

Unlike kdump, which passes the re-IPL parameter block through os_info,
the stand-alone dump passes it through the IPL parm block address and
checksum in lowcore.

Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not
provide an IPL parameter block. In this case reipl_type_init() selects
IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless,
dump_reipl_run() unconditionally dereferences it when preparing the
lowcore fields. This may happen to work by chance when address zero
contains readable lowcore data. A zero IPL parameter block address is
then stored in lowcore, causing the stand-alone dumper to enter disabled
wait after completing the dump.

Explicitly store a zero IPL parameter block address and checksum when no
re-IPL parameter block is available. This does not change the behavior:
the stand-alone dumper completes the dump and halts, while valid re-IPL
parameter blocks continue to be handled as before.

Fixes: 099b76513992 ("[S390] Automatic IPL after dump")
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
---
 arch/s390/kernel/ipl.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index 7024fc413715..68fdd5616dfe 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -1929,7 +1929,8 @@ static struct shutdown_action __refdata dump_action = {
 static void dump_reipl_run(struct shutdown_trigger *trigger)
 {
 	struct lowcore *abs_lc;
-	unsigned int csum;
+	unsigned long ipib = 0;
+	unsigned int csum = 0;
 
 	/*
 	 * Set REIPL_CLEAR flag in os_info flags entry indicating
@@ -1945,9 +1946,12 @@ static void dump_reipl_run(struct shutdown_trigger *trigger)
 	    reipl_type == IPL_TYPE_UNKNOWN)
 		os_info_flags |= OS_INFO_FLAG_REIPL_CLEAR;
 	os_info_entry_add_data(OS_INFO_FLAGS_ENTRY, &os_info_flags, sizeof(os_info_flags));
-	csum = (__force unsigned int)cksm(reipl_block_actual, reipl_block_actual->hdr.len, 0);
+	if (reipl_block_actual) {
+		ipib = __pa(reipl_block_actual);
+		csum = (__force unsigned int)cksm(reipl_block_actual, reipl_block_actual->hdr.len, 0);
+	}
 	abs_lc = get_abs_lowcore();
-	abs_lc->ipib = __pa(reipl_block_actual);
+	abs_lc->ipib = ipib;
 	abs_lc->ipib_checksum = csum;
 	put_abs_lowcore(abs_lc);
 	dump_run(trigger);
-- 
2.53.0

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

[sashiko-bot]

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.
--

--- Patch [1]: [PATCH 1/2] s390/ipl: Fix NULL deref in kdump without re-IPL parm block ---
commit f223a6548d3bfb367ccf07d1f7597eab8c386045
Author: Vasily Gorbik <gor@linux.ibm.com>

s390/ipl: Fix NULL deref in kdump without re-IPL parm block

Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might
not provide an IPL parameter block. In this case, reipl_type_init()
selects IPL_TYPE_UNKNOWN, and reipl_block_actual remains NULL.

> diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
> index 3c346b02ceb95..7024fc4137152 100644
> --- a/arch/s390/kernel/ipl.c
> +++ b/arch/s390/kernel/ipl.c
> @@ -1157,6 +1157,8 @@ static struct attribute_group reipl_nss_attr_group = {
>  
>  void set_os_info_reipl_block(void)
>  {
> +	if (!reipl_block_actual)
> +		return;
>  	os_info_entry_add_data(OS_INFO_REIPL_BLOCK, reipl_block_actual,
>  			       reipl_block_actual->hdr.len);
>  }

[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?

arch/s390/kernel/ipl.c:dump_reipl_run() {
    ...
	csum = (__force unsigned int)cksm(reipl_block_actual,
					  reipl_block_actual->hdr.len, 0);
	abs_lc = get_abs_lowcore();
	abs_lc->ipib = __pa(reipl_block_actual);
    ...
}

Will this cause a recursive fault during a crash shutdown sequence when the
on_panic action is configured to dump_reipl?

[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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/c00-02.ttjpfvt@ub.hpns?part=1

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

[sashiko-bot]

> Unlike kdump, which passes the re-IPL parameter block through os_info,
> the stand-alone dump passes it through the IPL parm block address and
> checksum in lowcore.
> 
> Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not
> provide an IPL parameter block. In this case reipl_type_init() selects
> IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless,
> dump_reipl_run() unconditionally dereferences it when preparing the
> lowcore fields. This may happen to work by chance when address zero
> contains readable lowcore data. A zero IPL parameter block address is
> then stored in lowcore, causing the stand-alone dumper to enter disabled
> wait after completing the dump.
> 
> Explicitly store a zero IPL parameter block address and checksum when no
> re-IPL parameter block is available. This does not change the behavior:
> the stand-alone dumper completes the dump and halts, while valid re-IPL
> parameter blocks continue to be handled as before.
> 
> Fixes: 099b76513992 ("[S390] Automatic IPL after dump")
> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/c00-02.ttjpfvt@ub.hpns?part=2

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

[Vasily Gorbik]

On Thu, Aug 13, 2026 at 11:19:27AM +0000, sashiko-bot@kernel.org 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.

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

[Mikhail Zaslonko]

On 13-Aug-26 13:06, Vasily Gorbik wrote:
> Unlike kdump, which passes the re-IPL parameter block through os_info,
> the stand-alone dump passes it through the IPL parm block address and
> checksum in lowcore.
> 
> Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not
> provide an IPL parameter block. In this case reipl_type_init() selects
> IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless,
> dump_reipl_run() unconditionally dereferences it when preparing the
> lowcore fields. This may happen to work by chance when address zero
> contains readable lowcore data. A zero IPL parameter block address is
> then stored in lowcore, causing the stand-alone dumper to enter disabled
> wait after completing the dump.
> 
> Explicitly store a zero IPL parameter block address and checksum when no
> re-IPL parameter block is available. This does not change the behavior:
> the stand-alone dumper completes the dump and halts, while valid re-IPL
> parameter blocks continue to be handled as before.
> 
> Fixes: 099b76513992 ("[S390] Automatic IPL after dump")
> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
> ---
>  arch/s390/kernel/ipl.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
> index 7024fc413715..68fdd5616dfe 100644
> --- a/arch/s390/kernel/ipl.c
> +++ b/arch/s390/kernel/ipl.c
> @@ -1929,7 +1929,8 @@ static struct shutdown_action __refdata dump_action = {
>  static void dump_reipl_run(struct shutdown_trigger *trigger)
>  {
>  	struct lowcore *abs_lc;
> -	unsigned int csum;
> +	unsigned long ipib = 0;
> +	unsigned int csum = 0;
>  
>  	/*
>  	 * Set REIPL_CLEAR flag in os_info flags entry indicating
> @@ -1945,9 +1946,12 @@ static void dump_reipl_run(struct shutdown_trigger *trigger)
>  	    reipl_type == IPL_TYPE_UNKNOWN)
>  		os_info_flags |= OS_INFO_FLAG_REIPL_CLEAR;
>  	os_info_entry_add_data(OS_INFO_FLAGS_ENTRY, &os_info_flags, sizeof(os_info_flags));
> -	csum = (__force unsigned int)cksm(reipl_block_actual, reipl_block_actual->hdr.len, 0);
> +	if (reipl_block_actual) {
> +		ipib = __pa(reipl_block_actual);
> +		csum = (__force unsigned int)cksm(reipl_block_actual, reipl_block_actual->hdr.len, 0);
> +	}
>  	abs_lc = get_abs_lowcore();
> -	abs_lc->ipib = __pa(reipl_block_actual);
> +	abs_lc->ipib = ipib;
>  	abs_lc->ipib_checksum = csum;
>  	put_abs_lowcore(abs_lc);
>  	dump_run(trigger);

Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>