Re: [tip:efi/core] efi/x86: Ignore unrealistically large option ROMs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14 May 2018 at 09:50, tip-bot for Hans de Goede <tipbot@xxxxxxxxx> wrote:
> Commit-ID:  1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f
> Gitweb:     https://git.kernel.org/tip/1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f
> Author:     Hans de Goede <hdegoede@xxxxxxxxxx>
> AuthorDate: Fri, 4 May 2018 08:00:01 +0200
> Committer:  Ingo Molnar <mingo@xxxxxxxxxx>
> CommitDate: Mon, 14 May 2018 08:57:49 +0200
>
> efi/x86: Ignore unrealistically large option ROMs
>
> setup_efi_pci() tries to save a copy of each PCI option ROM as this may
> be necessary for the device driver for the PCI device to have access too.
>
> On some systems the efi_pci_io_protocol's romimage and romsize fields
> contain invalid data, which looks a bit like pointers pointing back into
> other EFI code or data. Interpreting these pointers as romsize leads to
> a very large value and if we then try to alloc this amount of memory to
> save a copy the alloc call fails.
>
> This leads to a "Failed to alloc mem for rom" error being printed on the
> EFI console for each PCI device.
>
> This commit avoids the printing of these errors, by checking romsize before
> doing the alloc and if it is larger then the EFI spec limit of 16 MiB
> silently ignore the ROM fields instead of trying to alloc mem and fail.
>
> Tested-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> [ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant]
> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

This looks odd now: I sent this out as

Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
[ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant]
Tested-by: Hans de Goede <hdegoede@xxxxxxxxxx>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

which clearly conveys that Hans tested the updated version of the patch.

In general, I don't think there is a need to reorder signoffs unless
there is anything wrong with them, no?

> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: linux-efi@xxxxxxxxxxxxxxx
> Link: http://lkml.kernel.org/r/20180504060003.19618-16-ard.biesheuvel@xxxxxxxxxx
> Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
> ---
>  arch/x86/boot/compressed/eboot.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index dadf32312082..a8a8642d2b0b 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -123,10 +123,17 @@ __setup_efi_pci(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
>         if (status != EFI_SUCCESS)
>                 return status;
>
> +       /*
> +        * Some firmware images contain EFI function pointers at the place where the
> +        * romimage and romsize fields are supposed to be. Typically the EFI
> +        * code is mapped at high addresses, translating to an unrealistically
> +        * large romsize. The UEFI spec limits the size of option ROMs to 16
> +        * MiB so we reject any ROMs over 16 MiB in size to catch this.
> +        */
>         romimage = (void *)(unsigned long)efi_table_attr(efi_pci_io_protocol,
>                                                          romimage, pci);
>         romsize = efi_table_attr(efi_pci_io_protocol, romsize, pci);
> -       if (!romimage || !romsize)
> +       if (!romimage || !romsize || romsize > SZ_16M)
>                 return EFI_INVALID_PARAMETER;
>
>         size = romsize + sizeof(*rom);
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Stable Commits]     [Linux Stable Kernel]     [Linux Kernel]     [Linux USB Devel]     [Linux Video &Media]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux