current/SOURCES/s390-kexec-fix-ipl-report-address-for-kdump.patch

From c2337a40e04dde1692b5b0a46ecc59f89aaba8a1 Mon Sep 17 00:00:00 2001
From: Alexander Egorenkov <egorenar@linux.ibm.com>
Date: Mon, 14 Nov 2022 11:40:08 +0100
Subject: s390/kexec: fix ipl report address for kdump

From: Alexander Egorenkov <egorenar@linux.ibm.com>

commit c2337a40e04dde1692b5b0a46ecc59f89aaba8a1 upstream.

This commit addresses the following erroneous situation with file-based
kdump executed on a system with a valid IPL report.

On s390, a kdump kernel, its initrd and IPL report if present are loaded
into a special and reserved on boot memory region - crashkernel. When
a system crashes and kdump was activated before, the purgatory code
is entered first which swaps the crashkernel and [0 - crashkernel size]
memory regions. Only after that the kdump kernel is entered. For this
reason, the pointer to an IPL report in lowcore must point to the IPL report
after the swap and not to the address of the IPL report that was located in
crashkernel memory region before the swap. Failing to do so, makes the
kdump's decompressor try to read memory from the crashkernel memory region
which already contains the production's kernel memory.

The situation described above caused spontaneous kdump failures/hangs
on systems where the Secure IPL is activated because on such systems
an IPL report is always present. In that case kdump's decompressor tried
to parse an IPL report which frequently lead to illegal memory accesses
because an IPL report contains addresses to various data.

Cc: <stable@vger.kernel.org>
Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel")
Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/s390/kernel/machine_kexec_file.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/s390/kernel/machine_kexec_file.c
+++ b/arch/s390/kernel/machine_kexec_file.c
@@ -187,8 +187,6 @@ static int kexec_file_add_ipl_report(str
 
        data->memsz = ALIGN(data->memsz, PAGE_SIZE);
        buf.mem = data->memsz;
-       if (image->type == KEXEC_TYPE_CRASH)
-               buf.mem += crashk_res.start;
 
        ptr = (void *)ipl_cert_list_addr;
        end = ptr + ipl_cert_list_size;
@@ -225,6 +223,9 @@ static int kexec_file_add_ipl_report(str
                data->kernel_buf + offsetof(struct lowcore, ipl_parmblock_ptr);
        *lc_ipl_parmblock_ptr = (__u32)buf.mem;
 
+       if (image->type == KEXEC_TYPE_CRASH)
+               buf.mem += crashk_res.start;
+
        ret = kexec_add_buffer(&buf);
 out:
        return ret;
1	From c2337a40e04dde1692b5b0a46ecc59f89aaba8a1 Mon Sep 17 00:00:00 2001
2	From: Alexander Egorenkov <egorenar@linux.ibm.com>
3	Date: Mon, 14 Nov 2022 11:40:08 +0100
4	Subject: s390/kexec: fix ipl report address for kdump
5
6	From: Alexander Egorenkov <egorenar@linux.ibm.com>
7
8	commit c2337a40e04dde1692b5b0a46ecc59f89aaba8a1 upstream.
9
10	This commit addresses the following erroneous situation with file-based
11	kdump executed on a system with a valid IPL report.
12
13	On s390, a kdump kernel, its initrd and IPL report if present are loaded
14	into a special and reserved on boot memory region - crashkernel. When
15	a system crashes and kdump was activated before, the purgatory code
16	is entered first which swaps the crashkernel and [0 - crashkernel size]
17	memory regions. Only after that the kdump kernel is entered. For this
18	reason, the pointer to an IPL report in lowcore must point to the IPL report
19	after the swap and not to the address of the IPL report that was located in
20	crashkernel memory region before the swap. Failing to do so, makes the
21	kdump's decompressor try to read memory from the crashkernel memory region
22	which already contains the production's kernel memory.
23
24	The situation described above caused spontaneous kdump failures/hangs
25	on systems where the Secure IPL is activated because on such systems
26	an IPL report is always present. In that case kdump's decompressor tried
27	to parse an IPL report which frequently lead to illegal memory accesses
28	because an IPL report contains addresses to various data.
29
30	Cc: <stable@vger.kernel.org>
31	Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel")
32	Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
33	Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
34	Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
35	Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
36	---
37	arch/s390/kernel/machine_kexec_file.c \| 5 +++--
38	1 file changed, 3 insertions(+), 2 deletions(-)
39
40	--- a/arch/s390/kernel/machine_kexec_file.c
41	+++ b/arch/s390/kernel/machine_kexec_file.c
42	@@ -187,8 +187,6 @@ static int kexec_file_add_ipl_report(str
43
44	data->memsz = ALIGN(data->memsz, PAGE_SIZE);
45	buf.mem = data->memsz;
46	- if (image->type == KEXEC_TYPE_CRASH)
47	- buf.mem += crashk_res.start;
48
49	ptr = (void *)ipl_cert_list_addr;
50	end = ptr + ipl_cert_list_size;
51	@@ -225,6 +223,9 @@ static int kexec_file_add_ipl_report(str
52	data->kernel_buf + offsetof(struct lowcore, ipl_parmblock_ptr);
53	*lc_ipl_parmblock_ptr = (__u32)buf.mem;
54
55	+ if (image->type == KEXEC_TYPE_CRASH)
56	+ buf.mem += crashk_res.start;
57	+
58	ret = kexec_add_buffer(&buf);
59	out:
60	return ret;