Hello Ard, On Thu, Oct 31, 2024 at 11:44:00AM +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. First of all, *thank you* for the quick fix. A few questions/thoughts that are still bugging me. If you know the answer for any, I would appreciate hearing from you. 1) This patch protects the kernel from a broken firmware. It has nothing to do with the kernel code. The kernel is being a victim here. 2) The bug reported in [0], clearly found that the problem was likely introduced by 2e6871a632a99d9b9e2ce3a7847acabe99e5a26e[1] from a cold boot. How it might be related to 2e6871a632a99d9b9e2ce3a7847acabe99e5a26e ? 3) Does having 2e6871a632a99d9b9e2ce3a7847acabe99e5a26e make the firmware bug (EFI Memory Attribute Trable corruption) more visible by any chance? [1] https://bugzilla.suse.com/show_bug.cgi?id=1231465#c44 Thank you! --breno
