Committed. Btw, revision of the existing code in this function still welcome (not all memory corruption bugs associated with it are fixed).
On Thu, Sep 10, 2009 at 09:48:16PM +0200, Robert Millan wrote: > > These were spotted by Colin Watson. Unfortunately, users report that it > doesn't fix the problem for them. But the fix almost certainly looks good, > so I'm inclined to commit it. > > I'd appreciate if more people can review this code (my proposed changes and > the function as a whole). I can't see any other vector that could introduce > corruption, other than the VBE interrupt routine itself. > > -- > Robert Millan > > The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and > how) you may access your data; but nobody's threatening your freedom: we > still allow you to remove your data and not access it at all." > 2009-09-10 Robert Millan <rmh.g...@aybabtu.com> > > Fix memory corruption issue (spotted by Colin Watson). > > * kern/i386/pc/startup.S (grub_vbe_bios_getset_dac_palette): Fix bug > causing returned size to be stored in an incorrect memory location. > Fix use of uninitialized value when storing the returned size. > > Index: kern/i386/pc/startup.S > =================================================================== > --- kern/i386/pc/startup.S (revision 2583) > +++ kern/i386/pc/startup.S (working copy) > @@ -1761,18 +1761,18 @@ FUNCTION(grub_vbe_bios_getset_dac_palett > movw $0x4f08, %ax > int $0x10 > > - movw %ax, %dx /* real_to_prot destroys %eax. */ > + movw %ax, %cx /* real_to_prot destroys %eax. */ > > DATA32 call real_to_prot > .code32 > > /* Move result back to *dac_mask_size. */ > + xorl %eax, %eax > movb %bh, %al > movl %eax, (%edx) > > /* Return value in %eax. */ > - xorl %eax, %eax > - movw %dx, %ax > + movw %cx, %ax > > popl %ebx > popl %ebp > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
