[PATCH v5 3/9] mm/memory-failure: libstub: install the poisoned-memory EFI table

Breno Leitao leitao at debian.org
Tue Sep 15 07:00:02 PDT 2026


On Tue, Sep 15, 2026 at 01:15:27PM +0000, sashiko-bot at kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] mm: efi: integer overflow in poisoned memory bitmap allocation on 32-bit
> --
> 
> commit 591eef51f672049b14b50a75d67dac823925a19a
> Author: Breno Leitao <leitao at debian.org>
> 
> mm/memory-failure: libstub: install the poisoned-memory EFI table
> 
> This commit introduces a new poisoned-memory EFI table installed by the stub.
> It sizes a bitmap based on the UEFI memory map to describe the RAM span and
> allocates it as EFI_ACPI_RECLAIM_MEMORY so the next kernel does not take it
> as free RAM.
> 
> > diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
> > index 48f93f7758e9e..9c66e06c972c5 100644
> > --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> > +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> 
> [ ... ]
> 
> > +static struct linux_efi_poisoned_memory *efi_poison_alloc(u64 phys_base,
> > +							  u64 bitmap_size)
> > +{
> > +	struct linux_efi_poisoned_memory *pm;
> > +	efi_status_t status;
> > +
> > +	status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY,
> > +			     sizeof(*pm) + bitmap_size, (void **)&pm);
> 
> [Severity: High]
> Could this allocation size wrap around on 32-bit EFI architectures if the
> memory map is extremely sparse?

This feature is limited to 64-bits only, so, these wraps on 32-bit
architectures are not real:

config EFI_POISONED_MEMORY
	def_bool y
	depends on EFI_STUB && MEMORY_FAILURE && 64BIT



More information about the kexec mailing list