Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] Integer truncation in efi_poison_alloc leads to a massive heap buffer overflow during memset on 32-bit or mixed-mode systems. --
commit 626632820fe1fdcddc73aaeb109705cbddc9828c Author: Breno Leitao <[email protected]> Subject: mm/memory-failure: libstub: install the poisoned-memory EFI table This patch introduces functionality in the EFI stub to create and install a poisoned-memory EFI configuration table. It walks the UEFI memory map to find the RAM range and allocates a bitmap to track poisoned memory granules. > diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c > b/drivers/firmware/efi/libstub/efi-stub-helper.c > index 48f93f7758e9e..5cbe675491333 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: Critical] Could sizeof(*pm) + bitmap_size overflow 32 bits on 32-bit or mixed-mode systems? If the EFI memory map describes a very large physical address space (such as a 32PB physical address provided by an untrusted hypervisor in a TDX/SEV environment), bitmap_size could approach 4GB. Because the size argument to allocate_pool is a UINTN, a value like 0x100000008 (sizeof(*pm) + 0xFFFFFFF0) would truncate to 8 bytes on 32-bit EFI systems, resulting in an undersized allocation. > + if (status != EFI_SUCCESS) > + return NULL; > + > + pm->version = 1; > + pm->unit_size = EFI_POISON_UNIT_SIZE; > + pm->phys_base = phys_base; > + pm->size = bitmap_size; > + memset(pm->bitmap, 0, bitmap_size); [Severity: Critical] If the allocate_pool calculation overflowed and truncated as described above, does this memset trigger an out-of-bounds write regression? Since bitmap_size (e.g., 0xFFFFFFF0) fits within a 32-bit size_t, memset will use the large untruncated size, potentially overwriting up to 4GB of EFI boot services memory following the undersized allocation. > + > + return pm; > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
