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
next prev parent 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