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.
