From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9055 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] fix use of pointer after free in unsetenv Date: Tue, 5 Jan 2016 00:28:12 +0300 (MSK) Message-ID: References: <5689AA38.60108@openwall.com> <20160104030558.GT238@brightrain.aerifal.cx> <568A4ED2.9020609@openwall.com> <20160104210528.GX238@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1451942912 1089 80.91.229.3 (4 Jan 2016 21:28:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 21:28:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9068-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 04 22:28:31 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aGCg0-0003D7-9f for gllmg-musl@m.gmane.org; Mon, 04 Jan 2016 22:28:28 +0100 Original-Received: (qmail 1451 invoked by uid 550); 4 Jan 2016 21:28:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1426 invoked from network); 4 Jan 2016 21:28:24 -0000 In-Reply-To: <20160104210528.GX238@brightrain.aerifal.cx> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) Xref: news.gmane.org gmane.linux.lib.musl.general:9055 Archived-At: On Mon, 4 Jan 2016, Rich Felker wrote: > On Mon, Jan 04, 2016 at 06:47:36PM +0300, Alexander Monakov wrote: > > On Mon, 4 Jan 2016, Alexander Monakov wrote: > > > To me the implementation looks weird due to how it restarts scanning __environ > > > with 'goto again' from position 0 instead of current position. I can propose > > > the following rewrite (untested): > > The "goto again" is for the rare (generally malicious) case of > duplicate definitions, to ensure that unsetenv removes them all. Yes, but my point was that rewinding all the way back to i=0 looks odd -- I understood the need to scan all entries. > > Hm, there's no need to preserve relative order of env entries, is there? > > Yes, there is. If FOO=x and FOO=y both appear in environ[], > unsetenv("BAR") must not cause getenv("FOO") to change from "x" to > "y". Thanks, I did not consider that. I'm curious, is that just from QoI perspective, or also required somewhere? Alexander