netdev - Re: [PATCH bpf-next] [tools/bpf] fix a few ubsan warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b4524602-9bc9-f614-f8ee-d0f315fea7b5@fb.com>
Date:   Wed, 10 Apr 2019 16:24:44 +0000
From:   Yonghong Song <yhs@...com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Alexei Starovoitov <ast@...com>, Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next] [tools/bpf] fix a few ubsan warning



On 4/10/19 12:58 AM, Daniel Borkmann wrote:
> On 04/10/2019 02:37 AM, Yonghong Song wrote:
>> The issue is reported at https://github.com/libbpf/libbpf/issues/28.
>>
>> Basically, per C standard, for
>>    void *memcpy(void *dest, const void *src, size_t n)
>> if "dest" or "src" is NULL, regardless of whether "n" is 0 or not,
>> the result of memcpy is undefined. clang ubsan reported three such
>> instances in bpf.c with the following pattern:
>>    memcpy(dest, 0, 0).
>>
>> Although in practice, no known compiler will cause issues when
>> copy size is 0. Let us still fix the issue to silence ubsan
>> warnings.
>>
>> Signed-off-by: Yonghong Song <yhs@...com>
> 
> Applied, thanks. I fixed up $SUBJECT while applying to add a subsystem prefix.
> 
>> ---
>>   tools/lib/bpf/bpf.c | 19 +++++++++----------
>>   1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index a1db869a6fda..78f2400dd2d1 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -79,7 +79,6 @@ static inline int sys_bpf_prog_load(union bpf_attr *attr, unsigned int size)
>>   
>>   int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr)
>>   {
>> -	__u32 name_len = create_attr->name ? strlen(create_attr->name) : 0;
>>   	union bpf_attr attr;
>>   
>>   	memset(&attr, '\0', sizeof(attr));
>> @@ -89,8 +88,9 @@ int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr)
>>   	attr.value_size = create_attr->value_size;
>>   	attr.max_entries = create_attr->max_entries;
>>   	attr.map_flags = create_attr->map_flags;
>> -	memcpy(attr.map_name, create_attr->name,
>> -	       min(name_len, BPF_OBJ_NAME_LEN - 1));
>> +	if (create_attr->name)
>> +		memcpy(attr.map_name, create_attr->name,
>> +		       min(strlen(create_attr->name), BPF_OBJ_NAME_LEN - 1));
> 
> Any reason we don't simplify this to use strncpy() for all these occurrences?
No particular reason, just did not think that far :-)
Yes, strncpy instead of memcpy should work here as well.

> 
> Thanks,
> Daniel
>