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

[Jiri Slaby <jirislaby@kernel.org>]

On 15. 11. 24, 11:21, Ard Biesheuvel wrote:
> On Fri, 15 Nov 2024 at 11:10, Breno Leitao <leitao@debian.org> wrote:
>>
>> Hello Ard,
>>
>> On Thu, Oct 31, 2024 at 06:58:23PM +0100, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> 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