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
| ||
|
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!
Powered by blists - more mailing lists