On Fri, Nov 15, 2024 at 12:01:38PM +0100, Ard Biesheuvel wrote: > On Fri, 15 Nov 2024 at 11:51, Jiri Slaby <jirislaby@xxxxxxxxxx> wrote: > > > > 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.) > > > > Excellent. I'll take this as an ack from both of you. Thanks! I've just send a "formal" ack to keep it registered. Thanks again for solving it. --breno
