On Fri, Jan 19, 2018 at 9:41 AM, Jan Beulich <[email protected]> wrote: >>>> On 19.01.18 at 17:25, <[email protected]> wrote: >> On Fri, Jan 19, 2018 at 2:12 AM, Jan Beulich <[email protected]> wrote: >>> And then - how about a different heuristic altogether: Current >>> code scans the pointed to memory for a nul character, being >>> happy if it is found before having exhausted cmdsize. >> >> I'm not sure what you are talking about. The nul char is not at the >> end of the EFI_LOAD_OPTION, it is only at the end of the Description >> array. And we have to scan for it because the length of the >> Description array is not recorded anywhere else. So we scan for the >> nul char in the part of the buffer where it would be warranted by the >> EFI spec, then compute the location of the actual option buffer based >> on that checking that it is within bounds of the buffer. > > By "current code" I mean what's upstream at present, not yours. > I.e. I'm suggesting to consider proving it's a nul-terminated string > instead of proving its an EFI_LOAD_OPTION structure. >
Ah, yes, that makes more sense. For the EFI_LOAD_OPTION case we would still have to do all the parsing and sanity checking we currently do though. But adding a check to see whether the buffer ends in a nul and if it does skipping the EFI_LOAD_OPTION parsing would be fine. Tamas _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
