On 22/06/16 05:48, Laszlo Ersek wrote:
In other words, the memcpy() quoted at the top copies 32 bytes into a
32-byte buffer, from a 20-byte buffer. It is the *source* buffer that is
overflowed.
As a result, bytes 20..31 of MacAddress (inclusive) are filled with
garbage.
Awesome debugging; thank you! I've pushed a fix at
http://git.ipxe.org/ipxe.git/commitdiff/632e57f
The question is then, why does it cause issues? The answer boggles the
mind a bit. I mentioned in the earlier emails that the new Device
Manager uses a different type of IFR opcode for the sub-form selection.
I said that the opcode was callback-less, but much more importantly,
these opcodes (= EFI_IFR_REF4 or "goto" opcodes) store a *textual*
rendering of the device path that is associated with the HII package
list / form set that the individual driver installs.
Is this conceptually safe? Is the process of binary->text->binary
guaranteed to be lossless for any (valid) device path?
Also, what happens on systems that don't have DevicePathToTextProtocol?
Thanks,
Michael
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
