On 27/07/16 15:38, Matt Fleming wrote: > On Wed, 20 Jul, at 11:11:06AM, Colin Ian King wrote: >> From: Colin Ian King <[email protected]> >> >> Although very unlikey, if size is too small or zero, then we end up with >> status not being set and returning garbage. Instead, initializing status to >> EFI_INVALID_PARAMETER to indicate that size is invalid in the calls to >> setup_uga32 and setup_uga64. >> >> Signed-off-by: Colin Ian King <[email protected]> >> --- >> arch/x86/boot/compressed/eboot.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/x86/boot/compressed/eboot.c >> b/arch/x86/boot/compressed/eboot.c >> index ff574da..ec6d2ef 100644 >> --- a/arch/x86/boot/compressed/eboot.c >> +++ b/arch/x86/boot/compressed/eboot.c >> @@ -578,7 +578,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 >> *width, u32 *height) >> efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID; >> unsigned long nr_ugas; >> u32 *handles = (u32 *)uga_handle;; >> - efi_status_t status; >> + efi_status_t status = EFI_INVALID_PARAMETER; >> int i; >> >> first_uga = NULL; >> @@ -623,7 +623,7 @@ setup_uga64(void **uga_handle, unsigned long size, u32 >> *width, u32 *height) >> efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID; >> unsigned long nr_ugas; >> u64 *handles = (u64 *)uga_handle;; >> - efi_status_t status; >> + efi_status_t status = EFI_INVALID_PARAMETER; >> int i; >> >> first_uga = NULL; > > Can this ever happen in practice? This would imply that > locate_protocol() found EFI_UGA_PROTOCOL_GUID but that the size > returned is utterly bogus?
I just wanted to guard against the call efi_call_early(locate_handle, EFI_LOCATE_BY_PROTOCOL, &uga_proto, NULL, &size, uga_handle) returning a bogus size of less than a u32/u64 (depending on the setup_uga32/setup_uga64), which I was not 100% sure if this could happen or not, so I always assume efi_call_early calls can go wrong when you least expect them. > > If so, I have no problem applying the patch but want to make sure > we're not tricking ourselves into thinking we're being protected from > something when we're not. > I'd rather put extra guarding in rather than getting some potential garbage return from the stack, but I am playing it rather conservatively here. Colin
