mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: musl@lists.openwall.com
Subject: Re: [PATCH 1/3] overhaul environment functions
Date: Sun, 20 Mar 2016 07:15:52 +0300 (MSK)	[thread overview]
Message-ID: <alpine.LNX.2.20.1603200708060.10468@monopod.intra.ispras.ru> (raw)
In-Reply-To: <20160320002356.GX21636@brightrain.aerifal.cx>

On Sat, 19 Mar 2016, Rich Felker wrote:
> > > > +	static char **oldenv;
> > > > +	char **newenv;
> > > > +	if (__environ == oldenv) {
> > > > +		newenv = realloc(oldenv, sizeof *newenv * (i+2));
> > > > +		if (!newenv) goto oom;
> > > > +	} else {
> > > > +		newenv = malloc(sizeof *newenv * (i+2));
> > > > +		if (!newenv) goto oom;
> > > > +		if (i) memcpy(newenv, __environ, sizeof *newenv * i);
> > > > +		free(oldenv);
> > > > +	}
> > > 
> > > Rather than using malloc when __environ != oldenv, I think we should
> > > use realloc on oldenv, so that we don't leak internally-allocated
> > > environ arrays if the program repeatedly does environ=0 or calls your
> > > new clearenv.
> > 
> > How can we leak internally allocated environ here? If there's one, oldenv
> > points to it, and we free it right after memcpy.
> 
> for (;;) { clearenv(); putenv("FOO=BAR"); }
> 
> Since __environ!=oldenv at the time of every putenv call, each call
> allocates a new environment array and the old one is leaked.

But the old one is not leaked: like I said, 'free(oldenv)' frees it.

> > > >  	if (!overwrite && getenv(var)) return 0;
> > > >  
> > > > -	l1 = strlen(var);
> > > >  	l2 = strlen(value);
> > > >  	s = malloc(l1+l2+2);
> > > > -	if (s) {
> > > > -		memcpy(s, var, l1);
> > > > -		s[l1] = '=';
> > > > -		memcpy(s+l1+1, value, l2);
> > > > -		s[l1+l2+1] = 0;
> > > > -		if (!__putenv(s, 1)) return 0;
> > > > -	}
> > > > -	free(s);
> > > > -	return -1;
> > > > +	if (!s) return -1;
> > > > +	memcpy(s, var, l1);
> > > > +	s[l1] = '=';
> > > > +	memcpy(s+l1+1, value, l2+1);
> > > > +	return __putenv(s, l1, s);
> > > >  }
> > > 
> > > This leaks when __putenv fails. It's no worse than before but should
> > > probably be fixed.
> > 
> > Only when __env_change, specifically, "fails"; not when __putenv OOMs.
> 
> Why? s points to memory allocated by malloc, and I don't see anywhere
> it's freed if __putenv fails.

In old code there's explicit 'free(s)' on fallthrough path if __putenv
returned -1; in new code __putenv frees its last argument on oom itself
(at 'oom:' label).

Alexander


  reply	other threads:[~2016-03-20  4:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-13 18:53 [PATCH 0/3] env functions overhaul Alexander Monakov
2016-03-13 18:53 ` [PATCH 1/3] overhaul environment functions Alexander Monakov
2016-03-19 16:46   ` Rich Felker
2016-03-19 18:11     ` Alexander Monakov
2016-03-20  0:23       ` Rich Felker
2016-03-20  4:15         ` Alexander Monakov [this message]
2016-03-20 19:56           ` Rich Felker
2016-03-20 20:15             ` Alexander Monakov
2016-03-21 12:45               ` Alexander Monakov
2016-03-13 18:53 ` [PATCH 2/3] env: remove duplicates when adding to environment Alexander Monakov
2016-03-13 18:53 ` [PATCH 3/3] env: free allocations in clearenv Alexander Monakov

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=alpine.LNX.2.20.1603200708060.10468@monopod.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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).