From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33021-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 532 invoked by alias); 15 Aug 2014 17:16:59 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 33021
Received: (qmail 90 invoked from network); 15 Aug 2014 17:16:47 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <140815101701.ZM5288@torch.brasslantern.com>
Date: Fri, 15 Aug 2014 10:17:01 -0700
In-reply-to: <20140815112316.GA17063@localhost.localdomain>
Comments: In reply to Han Pingtian <hanpt@linux.vnet.ibm.com>
 "Re: zsh 5.0.5-dev-2" (Aug 15,  7:23pm)
References: <20140812212920.67dcb116@pws-pc.ntlworld.com>
	<29575.1407969294@thecus.kiddle.eu>
	<20140814093442.1a74c5b7@pwslap01u.europe.root.pri>
	<20140814103227.74c7d168@pwslap01u.europe.root.pri>
	<140814092045.ZM18007@torch.brasslantern.com>
	<20140814205429.44baf512@pws-pc.ntlworld.com>
	<140814214412.ZM4177@torch.brasslantern.com>
	<20140815112316.GA17063@localhost.localdomain>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: zsh-workers@zsh.org
Subject: Re: zsh 5.0.5-dev-2
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Aug 15,  7:23pm, Han Pingtian wrote:
} Subject: Re: zsh 5.0.5-dev-2
}
} Hi,
} 
} Looks like on the 747 line of Src/utils.c:
} 
} 747         sprintf(xbuf2, "%s/%s", xbuf, *pp);
} 
} The "cd .." will trigger a buffer overflow if I compile zsh with 
} -D FORTIFY_SOURCE=2 . Shall we return -1 here if it will overflow xbuf2?

I think Fortify errors because xbuf2 and xbuf are the same size and
the sprintf format is appending at least one character.  In practice
there would have to be a path segment PATH_MAX bytes long followed by
a file (directory) name at least PATH_MAX bytes long, which ought to
be impossible if the file system is well-behaved; in any other case
the readlink() will already have failed on the previous segment and
it already has either generated a partial expansion or returned -1.

If we're really worried about this, I think the solution would be to make
xbuf2 larger, e.g., PATH_MAX*3 or something.  Does the fortify error go
away if you increase the size of xbuf2?