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:   Mon, 25 May 2020 10:53:50 +0200
From:   Andrea Claudi <>
To:     Jamal Hadi Salim <>
Cc:     Daniel Borkmann <>,
        Stephen Hemminger <>,
        linux-netdev <>,
        David Ahern <>,
Subject: Re: [PATCH iproute2 v3 0/2] bpf: memory access fixes

On Sat, May 23, 2020 at 12:32 PM Jamal Hadi Salim <> 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?


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

Powered by blists - more mailing lists