linux-kernel - Re: [PATCH v2 bpf-next] libbpf: Fix signed overflow in ringbuf_process

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzY1bftPAj_hjE4SBVv2P1U7twW3FdRsvNP9kPCMe_NOjA@mail.gmail.com>
Date:   Mon, 3 May 2021 10:46:11 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Brendan Jackman <jackmanb@...gle.com>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        open list <linux-kernel@...r.kernel.org>,
        KP Singh <kpsingh@...nel.org>,
        Florent Revest <revest@...omium.org>
Subject: Re: [PATCH v2 bpf-next] libbpf: Fix signed overflow in ringbuf_process_ring

On Mon, May 3, 2021 at 5:01 AM Brendan Jackman <jackmanb@...gle.com> wrote:
>
> On Fri, 30 Apr 2021 at 18:31, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> >
> > On Thu, Apr 29, 2021 at 6:05 AM Brendan Jackman <jackmanb@...gle.com> wrote:
>
> > > Note: I feel a bit guilty about the fact that this makes the reader
> > > think about implicit conversions. Nobody likes thinking about that.
> > >
> > > But explicit casts don't really help with clarity:
> > >
> > >   return (int)min(cnt, (int64_t)INT_MAX); // ugh
> > >
> >
> > I'd go with
> >
> > if (cnt > INT_MAX)
> >     return INT_MAX;
> >
> > return cnt;
>
> Sure, it has all the same implicit casts/promotions but I guess it's
> clearer anyway.

I might be wrong, but given INT_MAX is defined as

#  define INT_MAX      2147483647

(notice no suffix specifying which type it is), this constant will be
interpreted by compiler as desired type in the given context. So in

if (cnt > INT_MAX)

INT_MAX should be a uint64_t constant. But even if not, it is
up-converted to int64_t with no loss anyway.

>
> > If you don't mind, I can patch it up while applying?
>
> Yes please do, thanks!

So while doing that I noticed that you didn't fix ring_buffer__poll(),
so I had to fix it up a bit more extensively. Please check the end
result in bpf tree and let me know if there are any problems with it:

2a30f9440640 ("libbpf: Fix signed overflow in ringbuf_process_ring")