On Fri, May 31, 2019 at 2:03 AM Ard Biesheuvel <[email protected]> wrote:
> > The input of name_size is signed long, gets compared against an unsigned > > long > > of a fixed size, then stored as a signed int (this is mostly okay because of > > the known max size), but it then gets passed to a function takes unsigned > > long > > without checking the range. > > > > Here, the input name_size is 0, limit also is 0, but limit - 1 = -1, and > > then > > casts to ULONGMAX to ucs2_as_utf8 and corrupts the stack storage with a > > size of > > only EFIVAR_SSDT_NAME_MAX. This is a legitimate bug, but anyone in a position to trigger this is also in a position to inject an arbitrary SSDT which then means arbitrary code execution in the kernel, so I don't think there's any security-relevant impact.
