On Thu, 30 May 2019 at 18:04, <bugzilla-daemon@xxxxxxxxxxxxxxxxxxx> wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=203761 > > Bug ID: 203761 > Summary: efivar_ssdt_iter is subject to stack corruption when > the input name_size is 0 > Product: EFI > Version: unspecified > Kernel Version: 4.18.0-20-generic > Hardware: Intel > OS: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Boot > Assignee: efi@xxxxxxxxxxxxxxxxxxxx > Reporter: steven.yutang@xxxxxxxxx > Regression: No > > Reported also at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830951 > > function efivar_ssdt_iter in efi.c has the following code: > > char utf8_name[EFIVAR_SSDT_NAME_MAX]; > int limit = min_t(unsigned long, EFIVAR_SSDT_NAME_MAX, name_size); > ucs2_as_utf8(utf8_name, name, limit - 1); > > In this short snippet of code, we can see typical issues due to unsigned long > <-> int casting. > > 1. mismatch of signedness. > 2. loss of precision. > > 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. >
