netdev - Re: [PATCH iproute2 v3 0/2] bpf: memory access fixes

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]

Date:   Mon, 25 May 2020 10:53:50 +0200
From:   Andrea Claudi <aclaudi@...hat.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Stephen Hemminger <stephen@...workplumber.org>,
        linux-netdev <netdev@...r.kernel.org>,
        David Ahern <dsahern@...il.com>, asmadeus@...ewreck.org
Subject: Re: [PATCH iproute2 v3 0/2] bpf: memory access fixes

On Sat, May 23, 2020 at 12:32 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>
> On 2020-05-22 9:33 p.m., Daniel Borkmann wrote:
> > On 5/18/20 3:00 PM, Jamal Hadi Salim wrote:
> >> ping?
> >>
> >> Note: these are trivial bug fixes.
> >
> > Looking at c0325b06382c ("bpf: replace snprintf with asprintf when
> > dealing with long buffers"),
> > I wonder whether it's best to just revert and redo cleanly from
> > scratch.. How much testing has
> > been performed on the original patch? We know it is causing regressions,
> > and looking Jamal's
> > 2nd patch we do have patterns all over the place wrt error path that go
> > like:
>
> Reverting c0325b06382c would work as well..
>
> Note: I believe Andrea's original goal was to just get rid of a
> compiler warning from sprintf(). Stephen suggested to use
> asprintf. Andrea's original solution to get rid of the compiler
> warning would suffice. Maybe then an additional code audit to
> ensure consistency on usage of s[n]printf could be done and
> resolved separately.
>

Reverting c0325b06382c will for sure fix the segfault identified by
Jamal and get rid of the problems highlighted by Daniel and others.
To fix the s[n]printf truncation warning we can simply check for its
return value. From the snprintf man page:

"a return value of size or more means that the output was truncated."
(caveat: until glibc 2.0.6 ret value for truncation is -1)

Jamal: if this works for you, I can submit an alternative to this
patch series doing what I proposed above. What do you think?

Regards,
Andrea

> Thanks for taking the time Daniel.
>
> cheers,
> jamal
>