[PATCH] kho: Prevent reuse of preserved pages after a reservation failure

[PATCH] kho: Prevent reuse of preserved pages after a reservation failure

[Chris Down]

kho_preserved_memory_reserve() reserves each range of preserved memory
in memblock and marks it noinit, but ignores both return values. Either
can fail when memblock has to grow its reserved array and can't find
room, which at this point in boot it may only take from KHO bootmem.
The boot then goes on as if the range were reserved, and two things
can follow:

- If the reservation failed, memblock_free_all() hands the range to the
  page allocator with the previous kernel's data still in it, while its
  KHO user still expects to restore it. A memfd preserved through LUO
  can then get back pages that belong to someone else. Oh dear!
- If only the noinit marking failed, the struct pages can be
  initialised later, wiping the KHO magic, so restoring the range fails.

Dropping the handover at this point isn't safe either. reserve_mem=
revives its regions from the handover before mm_core_init(), and
relies on this walk to reserve them.

Carrying on could hand out private data, so let's panic if either call
fails.

Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
Signed-off-by: Chris Down <chris@chrisdown.name>
---
 kernel/liveupdate/kexec_handover.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index eeec298aa9d6..0faa21ebb0cf 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -629,9 +629,14 @@ static int __init kho_preserved_memory_reserve(unsigned long key, void *data)
 	sz = 1UL << (order + PAGE_SHIFT);
 	page = kho_get_preserved_page(phys, order);
 
-	/* Reserve the memory preserved in KHO in memblock */
-	memblock_reserve(phys, sz);
-	memblock_reserved_mark_noinit(phys, sz);
+	/*
+	 * Reserve the memory preserved in KHO in memblock. It's too late to
+	 * drop the handover if that fails: reserve_mem may already have revived
+	 * regions from it.
+	 */
+	if (memblock_reserve(phys, sz) || memblock_reserved_mark_noinit(phys, sz))
+		panic("KHO: failed to reserve preserved memory %pa+%#llx\n",
+		      &phys, sz);
 	info.magic = KHO_PAGE_MAGIC;
 	info.order = order;
 	page->private = info.page_private;

base-commit: a0dc8eddbfdb6dd9c5c2b70eb66ab49cb1978425
-- 
2.54.0

Re: [PATCH] kho: Prevent reuse of preserved pages after a reservation failure

[Mike Rapoport]

Hi,

On Tue, Nov 10, 2026 at 11:09:30PM -0800, Chris Down wrote:
> kho_preserved_memory_reserve() reserves each range of preserved memory
> in memblock and marks it noinit, but ignores both return values. Either
> can fail when memblock has to grow its reserved array and can't find
> room, which at this point in boot it may only take from KHO bootmem.

Is it an LLM analysis or you seen this happen?

> The boot then goes on as if the range were reserved, and two things
> can follow:
 
> - If the reservation failed, memblock_free_all() hands the range to the
>   page allocator with the previous kernel's data still in it, while its
>   KHO user still expects to restore it. A memfd preserved through LUO
>   can then get back pages that belong to someone else. Oh dear!
> - If only the noinit marking failed, the struct pages can be
>   initialised later, wiping the KHO magic, so restoring the range fails.
> 
> Dropping the handover at this point isn't safe either. reserve_mem=
> revives its regions from the handover before mm_core_init(), and
> relies on this walk to reserve them.

reserve_mem_kho_revive() can memblock_reserve() its memory itself and we
can carry on, can't we?
 
> Carrying on could hand out private data, so let's panic if either call
> fails.
> 
> Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
> Signed-off-by: Chris Down <chris@chrisdown.name>
> ---
>  kernel/liveupdate/kexec_handover.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index eeec298aa9d6..0faa21ebb0cf 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -629,9 +629,14 @@ static int __init kho_preserved_memory_reserve(unsigned long key, void *data)
>  	sz = 1UL << (order + PAGE_SHIFT);
>  	page = kho_get_preserved_page(phys, order);
>  
> -	/* Reserve the memory preserved in KHO in memblock */
> -	memblock_reserve(phys, sz);
> -	memblock_reserved_mark_noinit(phys, sz);
> +	/*
> +	 * Reserve the memory preserved in KHO in memblock. It's too late to
> +	 * drop the handover if that fails: reserve_mem may already have revived
> +	 * regions from it.
> +	 */
> +	if (memblock_reserve(phys, sz) || memblock_reserved_mark_noinit(phys, sz))
> +		panic("KHO: failed to reserve preserved memory %pa+%#llx\n",
> +		      &phys, sz);
>  	info.magic = KHO_PAGE_MAGIC;
>  	info.order = order;
>  	page->private = info.page_private;
> 
> base-commit: a0dc8eddbfdb6dd9c5c2b70eb66ab49cb1978425
> -- 
> 2.54.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH] kho: Prevent reuse of preserved pages after a reservation failure

[Chris Down]

Hi Mike,

Mike Rapoport writes:
>On Tue, Nov 10, 2026 at 11:09:30PM -0800, Chris Down wrote:
>> kho_preserved_memory_reserve() reserves each range of preserved memory
>> in memblock and marks it noinit, but ignores both return values. Either
>> can fail when memblock has to grow its reserved array and can't find
>> room, which at this point in boot it may only take from KHO bootmem.
>
>Is it an LLM analysis or you seen this happen?

Are those the only two options nowadays! :-) In this case it's just eyeballs.

I happened to notice this while preparing my KHO/LUO observability patchset and 
thought it made sense to send as a separate patch, since it doesn't depend on 
anything there.

It's probably realistically quite unlikely, I would think it would require a 
lot of fragmentation or a very small kho_bootmem=.

>> Dropping the handover at this point isn't safe either. reserve_mem=
>> revives its regions from the handover before mm_core_init(), and
>> relies on this walk to reserve them.
>
>reserve_mem_kho_revive() can memblock_reserve() its memory itself and we
>can carry on, can't we?

Thanks, that's better. I had thought carryong on wasn't possible because 
reserve_mem has already reserved its regions by the time we get to the walk, 
but actually you're right that there's no reason reserve_mem_kho_revive() can't 
just do it itself...

Looking at the code one thing we would likely trip over then is that 
kho_mem_retrieve()'s error path only clears fdt_phys, but not bootmem_phys.  
kho_init() then thinks that it's a cold boot and runs 
init_cma_reserved_pageblock() over the inherited bootmem which has already been 
handed to the buddy allocator, so this would need adjustment first.

So then, let me send v2 with reserve_mem_kho_revive() sorting out its own 
range, and making kho_init() skip the bootmem setup when the bootmem was 
inherited, if that sounds good?

Thanks!

Chris