When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page
Other architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Cc: stable@vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb paul.x.webb@oracle.com Signed-off-by: Harshit Mogalapalli harshit.m.mogalapalli@oracle.com --- Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the above patch works good. Paul initially reported this on 6.12 kernel but I was able to reproduce this on 6.18, so I tried replicating how this was fixed in drivers/of/kexec.c --- arch/x86/kernel/setup.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e1..fcef197d180e 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
int __init ima_get_kexec_buffer(void **addr, size_t *size) { + unsigned long start_pfn, end_pfn; + if (!ima_kexec_buffer_size) return -ENOENT;
+ /* + * Calculate the PFNs for the buffer and ensure + * they are with in addressable memory. + */ + start_pfn = PFN_DOWN(ima_kexec_buffer_phys); + end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1); + if (!pfn_range_is_mapped(start_pfn, end_pfn)) { + pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n", + ima_kexec_buffer_phys, ima_kexec_buffer_size); + return -EINVAL; + } + *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size;
[Cc: Roberto Sassu, linux-integrity]
On Tue, 2025-12-02 at 08:16 +0100, Ard Biesheuvel wrote:
On Mon, 1 Dec 2025 at 22:43, Mimi Zohar zohar@linux.ibm.com wrote:
On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
Hi all,
On 13/11/25 01:00, Harshit Mogalapalli wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
It should be obvious that without carrying the measurement list across kexec, that attestation will fail. Please mention it here in the patch description.
Couldn't we just use memremap() and be done with it? That will use the direct map if the memory is mapped, or vmap() it otherwise.
No, the IMA measurement list is not a continuous buffer, but a linked list of records with varying types of fields and field sizes. The call to ima_dump_measurement_list() marshals the measurement list into a buffer, while ima_restore_measurement_list() unmarshals it.
Hi all,
On 13/11/25 01:00, Harshit Mogalapalli wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Cc: stable@vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb paul.x.webb@oracle.com Signed-off-by: Harshit Mogalapalli harshit.m.mogalapalli@oracle.com
Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the above patch works good. Paul initially reported this on 6.12 kernel but I was able to reproduce this on 6.18, so I tried replicating how this was fixed in drivers/of/kexec.c
ping on this patch.
lore URL: https://lore.kernel.org/all/20251112193005.3772542-1-harshit.m.mogalapalli@o...
Thanks, Harshit
arch/x86/kernel/setup.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e1..fcef197d180e 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) {
- unsigned long start_pfn, end_pfn;
- if (!ima_kexec_buffer_size) return -ENOENT;
- /*
* Calculate the PFNs for the buffer and ensure* they are with in addressable memory.*/- start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
- end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
- if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",ima_kexec_buffer_phys, ima_kexec_buffer_size);return -EINVAL;- }
- *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size;
On Wed, Nov 12, 2025 at 11:30:02AM -0800, Harshit Mogalapalli wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Cc: stable@vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb paul.x.webb@oracle.com Signed-off-by: Harshit Mogalapalli harshit.m.mogalapalli@oracle.com
Seems legit; this applies on the loaded kernel side, so we do end up losing the measurements but that matches what OF does.
Reviewed-by: Jonathan McDowell noodles@meta.com
Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the above patch works good. Paul initially reported this on 6.12 kernel but I was able to reproduce this on 6.18, so I tried replicating how this was fixed in drivers/of/kexec.c
arch/x86/kernel/setup.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e1..fcef197d180e 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) {
- unsigned long start_pfn, end_pfn;
- if (!ima_kexec_buffer_size) return -ENOENT;
- /*
* Calculate the PFNs for the buffer and ensure* they are with in addressable memory.*/- start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
- end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
- if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",ima_kexec_buffer_phys, ima_kexec_buffer_size);return -EINVAL;- }
- *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size;
2.50.1
On Wed, 12 Nov 2025 11:30:02 -0800 Harshit Mogalapalli harshit.m.mogalapalli@oracle.com wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Thanks.
Cc: stable@vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
That was via the x86 tree so I assume the x86 team (Boris?) will be processing this patch.
I'll put it into mm.git's mm-hotfixes branch for now, to get a bit of testing and to generally track its progress.
--- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) {
- unsigned long start_pfn, end_pfn;
- if (!ima_kexec_buffer_size) return -ENOENT;
- /*
* Calculate the PFNs for the buffer and ensure* they are with in addressable memory.
"within" ;)
*/- start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
- end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
- if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",ima_kexec_buffer_phys, ima_kexec_buffer_size);return -EINVAL;- }
- *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size;
On Mon, Dec 01, 2025 at 09:20:20AM -0800, Andrew Morton wrote:
On Wed, 12 Nov 2025 11:30:02 -0800 Harshit Mogalapalli harshit.m.mogalapalli@oracle.com wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Then why isn't there a ima_validate_range() function there which everyone calls instead of the same check being replicated everywhere?
Cc: stable@vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
That was via the x86 tree so I assume the x86 team (Boris?) will be processing this patch.
Yeah, it is on my to-deal-with-after-the-merge-window pile.
But since you've forced my hand... :-P
I'll put it into mm.git's mm-hotfixes branch for now, to get a bit of testing and to generally track its progress.
--- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) {
- unsigned long start_pfn, end_pfn;
- if (!ima_kexec_buffer_size) return -ENOENT;
- /*
* Calculate the PFNs for the buffer and ensure* they are with in addressable memory."within" ;)
*/- start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
- end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
- if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",
This error message needs to be made a lot more user-friendly.
And pls do a generic helper as suggested above which ima code calls.
And by looking at the diff, there are two ima_get_kexec_buffer() functions in the tree which could use some unification too ontop.
Right?
Thx.
On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
Hi all,
On 13/11/25 01:00, Harshit Mogalapalli wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
It should be obvious that without carrying the measurement list across kexec, that attestation will fail. Please mentioned it here in the patch description.
Cc: stable@vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb paul.x.webb@oracle.com Signed-off-by: Harshit Mogalapalli harshit.m.mogalapalli@oracle.com
Tested-by: Mimi Zohar zohar@linux.ibm.com
On Mon, 1 Dec 2025 at 22:43, Mimi Zohar zohar@linux.ibm.com wrote:
On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
Hi all,
On 13/11/25 01:00, Harshit Mogalapalli wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
It should be obvious that without carrying the measurement list across kexec, that attestation will fail. Please mentioned it here in the patch description.
Couldn't we just use memremap() and be done with it? That will use the direct map if the memory is mapped, or vmap() it otherwise.
linux-stable-mirror@lists.linaro.org
-
Andrew Morton -
Ard Biesheuvel -
Borislav Petkov -
Harshit Mogalapalli -
Jonathan McDowell -
Mimi Zohar