Re: [Xen-devel] PING ARM [PATCH v2] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 18:16, <julien.grall@xxxxxxx> wrote:
> Hi Andrew,
> 
> On 14/01/2019 16:59, Andrew Cooper wrote:
>> On 14/01/2019 16:07, Julien Grall wrote:
>>> On 14/01/2019 15:17, Andrew Cooper wrote:
>>>>> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
>>>>> index ca655ff..22a86ec 100644
>>>>> --- a/xen/arch/arm/efi/efi-boot.h
>>>>> +++ b/xen/arch/arm/efi/efi-boot.h
>>>>> @@ -212,7 +212,7 @@ EFI_STATUS __init
>>>>> fdt_add_uefi_nodes(EFI_SYSTEM_TABLE *sys_table,
>>>>>                break;
>>>>>              type = fdt_getprop(fdt, node, "device_type", &len);
>>>>> -        if ( type && strncmp(type, "memory", len) == 0 )
>>>>> +        if ( type && len == 6 && strncmp(type, "memory", 6) == 0 )
>>>
>>> string property terminates with NUL and is included in the len. So I
>>> don't think this change is correct.
>> 
>> Are you saying that len is 7 here then?
> 
> Yes. But I don't think this change is necessary as we already include NUL in 
> the 
> comparison.

If len is 7, then indeed you do. Looking at fdt_get_property_by_offset()
I can't see though where the guarantee comes from that the returned
string is nul-terminated, as it's prop->len which gets handed back. IOW
if you e.g. get back "mem" (with or without a nul terminator) and len 3,
then strncmp() would still return zero.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel