[systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

[Robert P. J. Day]

On Fri, 19 Feb 2021, Reindl Harald wrote:

>
>
> Am 19.02.21 um 11:28 schrieb Robert P. J. Day:
> >    I *may* have found the problem ... as one can read here:
> >
> > https://access.redhat.com/solutions/3840481
> >
> > "CVE-2019-3815 systemd: memory leak in journald-server.c introduced by
> > fix for CVE-2018-16864"
> >
> >    So as I interpret that, a memory leak introduced by that earlier CVE
> > had to be corrected by that later CVE. I checked the state of
> > systemd_230 as shipped by WRL9, and it comes with an extensive set of
> > patches, which includes the earlier CVE, but *not* the later one.
> >
> >    Hmmmmmmm ...
>
> that one should have been fixed long ago
> https://bugzilla.redhat.com/show_bug.cgi?id=1665931

  while i'm jumping back into this, a possibly silly question ...
where in the systemd commit log can i find the commit corresponding to
the "fix" associated with CVE-2019-3815?

  i wanted to see the original commit that introduced the bug, so i
naturally used:

  $ git log --grep="CVE-2018-16864"

and there it was. but i get nothing from:

  $ git log --grep="CVE-2019-3815"

after a bit of reading, i landed on:

  $ git log -p --grep="don't use overly large buffer"

  commit eb1ec489eef8a32918bbfc56a268c9d10464584d
  Author: Michal Sekletár <msekleta at redhat.com>
  Date:   Tue Jan 22 14:29:50 2019 +0100

    process-util: don't use overly large buffer to store process command line

    Allocate new string as a return value and free our "scratch pad"
    buffer that is potentially much larger than needed (up to
    _SC_ARG_MAX).

    Fixes #11502

    ... etc etc ...

i guess i expected that the CVE identifier would be in the commit
message. anyway, time to examine ...

rday

p.s. my first concern is whether this is a standalone patch that i can
shoehorn into systemd_230, or whether i can just drag the entire
version forward to the point where it incorporates that fix. that
might take a bit of work given the distance involved.