netdev - Re: [PATCH bpf] libbpf: Prevent overriding errno when logging errors

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 PHC
Open Source and information security mailing list archives

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

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

Date:   Thu, 13 Aug 2020 22:35:07 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf] libbpf: Prevent overriding errno when logging errors

On 8/13/20 9:52 PM, Toke Høiland-Jørgensen wrote:
> Andrii Nakryiko <andrii.nakryiko@...il.com> writes:
>> On Thu, Aug 13, 2020 at 7:29 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>>>
>>> Turns out there were a few more instances where libbpf didn't save the
>>> errno before writing an error message, causing errno to be overridden by
>>> the printf() return and the error disappearing if logging is enabled.
>>>
>>> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>>> ---
>>
>> Acked-by: Andrii Nakryiko <andriin@...com>
>>
>>>   tools/lib/bpf/libbpf.c | 12 +++++++-----
>>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index 0a06124f7999..fd256440e233 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -3478,10 +3478,11 @@ bpf_object__probe_global_data(struct bpf_object *obj)
>>>
>>>          map = bpf_create_map_xattr(&map_attr);
>>>          if (map < 0) {
>>> -               cp = libbpf_strerror_r(errno, errmsg, sizeof(errmsg));
>>> +               ret = -errno;
>>> +               cp = libbpf_strerror_r(-ret, errmsg, sizeof(errmsg));
>>
>> fyi, libbpf_strerror_r() is smart enough to work with both negative
>> and positive error numbers (it basically takes abs(err)), so no need
>> to ensure it's positive here and below.
> 
> Noted. Although that also means it doesn't hurt either, I suppose; so
> not going to bother respinning this unless someone insists :)

Fixed up while applying, thanks!