If the firmware happens to return 0 as an address of allocated pages,
grub_efi_allocate_pages_real() tries to allocate a new set of pages,
and then free the ones at address 0.
However at that point grub_efi_store_alloc() wasn't yet called, so
freeing the pages at 0 using grub_efi_free_pages() which calls
grub_efi_drop_alloc() isn't necessary, so let's call b->free_pages()
instead.
The call to grub_efi_drop_alloc() doesn't seem particularly harmful,
because it seems to do nothing if the allocation it is asked to drop
isn't on the list, but the call to it is obviously unnecessary here.
Signed-off-by: Mate Kukri <mate.ku...@canonical.com>
---
grub-core/kern/efi/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index 4fec188ae..661319194 100644
--- a/grub-core/kern/efi/mm.c
+++ b/grub-core/kern/efi/mm.c
@@ -150,7 +150,7 @@ grub_efi_allocate_pages_real (grub_efi_physical_address_t
address,
so reallocate another one. */
address = GRUB_EFI_MAX_USABLE_ADDRESS;
status = b->allocate_pages (alloctype, memtype, pages, &address);
- grub_efi_free_pages (0, pages);
+ b->free_pages (0, pages);
if (status != GRUB_EFI_SUCCESS)
{
grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
--
2.39.2
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
