public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Andrea Claudi <aclaudi@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	linux-netdev <netdev@vger.kernel.org>,
	David Ahern <dsahern@gmail.com>,
	daniel@iogearbox.net, Jamal Hadi Salim <hadi@mojatatu.com>
Subject: Re: [PATCH iproute2 1/1] bpf: Fix segfault when custom pinning is used
Date: Tue, 21 Apr 2020 15:58:36 -0400	[thread overview]
Message-ID: <478bfaf8-6418-2d37-cae6-88b113d686b0@mojatatu.com> (raw)
In-Reply-To: <CAPpH65zGO02uQyWQXXq6Yg_zsZcVZg+4-KWfRo_q3iACHr6s_Q@mail.gmail.com>

Hi Andrea,

On 2020-04-21 3:38 p.m., Andrea Claudi wrote:
[..]
> 
> Hi Jamal,
> Are you sure this fixes your issue?

Yes.

> I think asprintf could segfault
> only if ctx is null, but this case is not addressed in your patch.

The issue is tmp(after it is created by asprintf) gets trampled.
This:
ret = asprintf(&tmp, "%s/../", bpf_get_work_dir(ctx->type));
allocates enough space for tmp.
But then later:
strcat(tmp, sub);
strcat(tmp...);
creates a buffer overrun.

It is easy to overlook things like these when making a large
semantically-equivalent change - so i would suggest to also
review the general patch that went from sprintf->asprintf.

> I remember that Stephen asked me to use asprintf to avoid allocating
> huge buffers on stack; anyway I've no objection to sprintf, if needed.

Generally that is good practise. And even for this case
you could probably find a simpler way to solve it with asprintf
or realloc trickery. I am not sure it is worth the bother - 4K on
the stack in user space is not a big deal really.

cheers,
jamal

  reply	other threads:[~2020-04-21 19:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 18:04 [PATCH iproute2 1/1] bpf: Fix segfault when custom pinning is used Jamal Hadi Salim
2020-04-21 19:38 ` Andrea Claudi
2020-04-21 19:58   ` Jamal Hadi Salim [this message]
2020-04-21 22:10     ` Andrea Claudi
2020-04-22  6:42 ` Dominique Martinet
2020-04-22  9:47   ` Jamal Hadi Salim

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=478bfaf8-6418-2d37-cae6-88b113d686b0@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=aclaudi@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=hadi@mojatatu.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox