[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PING ARM [PATCH v2] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct
Hi Jan, On 1/15/19 8:47 AM, Jan Beulich wrote: 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. From section 2.2.4, when the propery value is a string then it should be null-terminated. So your example is invalid from a DT spec point of view. Validating a Device-Tree (other than the bindings) is a pain so you always have to provide a blob complaint with the spec [1]. Cheers,[1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2 Jan -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |