On Tue, Aug 23, 2022 at 01:55:26AM +1000, Daniel Axtens wrote: > Daniel Axtens <d...@axtens.net> writes: > > > This is 'belt and braces' with the last fix: we end up trying to use > > too much memory in situations like corrupted Linux software raid setups > > purporting to usew a huge number of disks. Simply refuse to permit such > > configurations. > > > > 1024 is a bit arbitrary, yes, and I feel a bit like I'm tempting fate > > here, but I think 1024 disks in an array (that grub has to read to boot!) > > should be enough for anyone. > > > > Signed-off-by: Daniel Axtens <d...@axtens.net> > > --- > > grub-core/disk/diskfilter.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/grub-core/disk/diskfilter.c b/grub-core/disk/diskfilter.c > > index 4ac50320ef4e..79c5f4db940a 100644 > > --- a/grub-core/disk/diskfilter.c > > +++ b/grub-core/disk/diskfilter.c > > @@ -1046,6 +1046,13 @@ grub_diskfilter_make_raid (grub_size_t uuidlen, char > > *uuid, int nmemb, > > struct grub_diskfilter_pv *pv; > > grub_err_t err; > > > > + /* We choose not to support more than 1024 disks */ > > + if (nmemb > 1024) > > Ergh, nmemb is an int; I will do a v2 that also checks that it's greater > than 0 (or 1, given that it's RAID? I will do some tests.)
Could you repost this patch with the fix? Or both with my RB for first one... Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
