Re: [PATCH v2] efi/memattr: Ignore table if the size is clearly bogus

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

 



On 15. 11. 24, 11:21, Ard Biesheuvel wrote:
On Fri, 15 Nov 2024 at 11:10, Breno Leitao <leitao@xxxxxxxxxx> wrote:

Hello Ard,

On Thu, Oct 31, 2024 at 06:58:23PM +0100, Ard Biesheuvel wrote:
From: Ard Biesheuvel <ardb@xxxxxxxxxx>

There are reports [0] of cases where a corrupt EFI Memory Attributes
Table leads to out of memory issues at boot because the descriptor size
and entry count in the table header are still used to reserve the entire
table in memory, even though the resulting region is gigabytes in size.

Given that the EFI Memory Attributes Table is supposed to carry up to 3
entries for each EfiRuntimeServicesCode region in the EFI memory map,
and given that there is no reason for the descriptor size used in the
table to exceed the one used in the EFI memory map, 3x the size of the
entire EFI memory map is a reasonable upper bound for the size of this
table. This means that sizes exceeding that are highly likely to be
based on corrupted data, and the table should just be ignored instead.

I haven't seen this patch landing in net-next tree yet.
Do you have plan to have this merged into 6.13?


Nobody replied to it, so I wasn't going to.

Would you like this patch to be taken for v6.13? Does it fix the
issues you have been observing?

For the reporter at:
  https://bugzilla.suse.com/show_bug.cgi?id=1231465#c50
definitely!

I was expected this to land in the tree too... (Without any further notifications to you.)

thanks,
--
js
suse labs




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux