All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mahesh Bandewar (महेश बंडेवार)" <maheshb@google.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Mahesh Bandewar <mahesh@bandewar.net>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH iproute2] iproute2: fix use-after-free
Date: Thu, 13 Sep 2018 10:54:42 -0700	[thread overview]
Message-ID: <CAF2d9jg6-nZq9tXG6xg8Mu1A0-W+13Jj-YCaXQAAKxWg08rj0A@mail.gmail.com> (raw)
In-Reply-To: <20180913081948.1bf8368b@xeon-e3>

On Thu, Sep 13, 2018 at 8:19 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 12 Sep 2018 23:07:20 -0700
> Mahesh Bandewar (महेश बंडेवार) <maheshb@google.com> wrote:
>
> > On Wed, Sep 12, 2018 at 5:33 PM, Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Wed, 12 Sep 2018 16:29:28 -0700
> > > Mahesh Bandewar <mahesh@bandewar.net> wrote:
> > >
> > > > From: Mahesh Bandewar <maheshb@google.com>
> > > >
> > > > A local program using iproute2 lib pointed out the issue and looking
> > > > at the code it is pretty obvious -
> > > >
> > > >     a = (struct nlmsghdr *)b;
> > > >     ...
> > > >     free(b);
> > > >     if (a->nlmsg_seq == seq)
> > > >     ...
> > > >
> > > > Fixes: 86bf43c7c2fd ("lib/libnetlink: update rtnl_talk to support malloc buff at run time")
> > > > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> > >
> > > Yes, this is a real problem.
> > >
> > > Maybe a minimal patch like this would be enough:
> > actually that will leave the memory leak at the 'goto next' line (just
> > few lines below) since that jump will overwrite the buf.
>
> It looks like everytime in the while loop. a new buffer is allocated.
> So yes, it looks like old, my patch, and your patch would leak there
> was an error followed by other data in response.
> Though I doubt kernel would ever do that.
>
I started fixing the issue that I reported and then found-out the
memory leak and hence the first attempt of simple fix went into fixing
free-after-use as well as memory leak (in my patch). I'm not going to
claim that I know how and where this gets used, but my attempt was to
simply fix those two issues. I don't mind which fix you apply as long
as these issues get addressed.

> The only user of iov style messages to the kernel is in tc batching.
> My gut feeling is that if one message in batch has error, then
> the netlink code should return that error and stop processing more.

      reply	other threads:[~2018-09-13 23:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 23:29 [PATCH iproute2] iproute2: fix use-after-free Mahesh Bandewar
2018-09-13  0:33 ` Stephen Hemminger
2018-09-13  6:07   ` Mahesh Bandewar (महेश बंडेवार)
2018-09-13 15:19     ` Stephen Hemminger
2018-09-13 17:54       ` Mahesh Bandewar (महेश बंडेवार) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAF2d9jg6-nZq9tXG6xg8Mu1A0-W+13Jj-YCaXQAAKxWg08rj0A@mail.gmail.com \
    --to=maheshb@google.com \
    --cc=mahesh@bandewar.net \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.