netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Jamal Hadi Salim <jhs@mojatatu.com>, stephen@networkplumber.org
Cc: netdev@vger.kernel.org, dsahern@gmail.com, aclaudi@redhat.com,
	asmadeus@codewreck.org
Subject: Re: [PATCH iproute2 v3 0/2] bpf: memory access fixes
Date: Sat, 23 May 2020 03:33:47 +0200	[thread overview]
Message-ID: <e192690f-ad1a-14c1-8052-e1a3fc0a1b8f@iogearbox.net> (raw)
In-Reply-To: <1d1e025b-346b-d5f7-6c44-da5a64f31a2c@mojatatu.com>

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:

   +	char *file = NULL;
   +	char buff[4096];
  	FILE *fp;
   +	int ret;

   -	snprintf(file, sizeof(file), "/proc/%d/fdinfo/%d", getpid(), fd);
   +	ret = asprintf(&file, "/proc/%d/fdinfo/%d", getpid(), fd);
   +	if (ret < 0) {
   +		fprintf(stderr, "asprintf failed: %s\n", strerror(errno));
   +		free(file);
   +		return ret;
   +	}

The man page on asprintf(char **strp, ...) says: "When successful, these functions return
the number of bytes printed, just like sprintf(3). If memory allocation wasn't possible,
or some other error occurs, these functions will return -1, and the contents of strp are
undefined." What is the rationale that are we passing it to free() /everywhere/ in error
path when the API spec does say it's undefined? It may happen to work but file's value
could just as well be, say, 42 ...

Thanks,
Daniel

> cheers,
> jamal
> 
> On 2020-04-28 12:15 p.m., Jamal Hadi Salim wrote:
>> Stephen,
>> What happened to this?
>>
>> cheers,
>> jamal
>>
>> On 2020-04-23 1:58 p.m., Jamal Hadi Salim wrote:
>>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>>
>>> Changes from V2:
>>>   1) Dont initialize tmp on stack (Stephen)
>>>   2) Dont look at the return code of snprintf (Dominique)
>>>   3) Set errno to EINVAL instead of returning -EINVAL for consistency (Dominique)
>>>
>>> Changes from V1:
>>>   1) use snprintf instead of sprintf and fix corresponding error message.
>>>   Caught-by: Dominique Martinet <asmadeus@codewreck.org>
>>>   2) Fix memory leak and extraneous free() in error path
>>>
>>> Jamal Hadi Salim (2):
>>>    bpf: Fix segfault when custom pinning is used
>>>    bpf: Fix mem leak and extraneous free() in error path
>>>
>>>   lib/bpf.c | 17 +++++++----------
>>>   1 file changed, 7 insertions(+), 10 deletions(-)
>>>
>>
> 


  reply	other threads:[~2020-05-23  1:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 17:58 [PATCH iproute2 v3 0/2] bpf: memory access fixes Jamal Hadi Salim
2020-04-23 17:58 ` [PATCH iproute2 v3 1/2] bpf: Fix segfault when custom pinning is used Jamal Hadi Salim
2020-04-23 17:58 ` [PATCH iproute2 v3 2/2] bpf: Fix mem leak and extraneous free() in error path Jamal Hadi Salim
2020-04-24 16:58 ` [PATCH iproute2 v3 0/2] bpf: memory access fixes Andrea Claudi
2020-04-28 16:15 ` Jamal Hadi Salim
2020-05-18 13:00   ` Jamal Hadi Salim
2020-05-23  1:33     ` Daniel Borkmann [this message]
2020-05-23 10:32       ` Jamal Hadi Salim
2020-05-25  8:53         ` Andrea Claudi
2020-05-26 12:27           ` 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=e192690f-ad1a-14c1-8052-e1a3fc0a1b8f@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=aclaudi@redhat.com \
    --cc=asmadeus@codewreck.org \
    --cc=dsahern@gmail.com \
    --cc=jhs@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;
as well as URLs for NNTP newsgroup(s).