From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33024-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 12621 invoked by alias); 16 Aug 2014 00:45:30 -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: 33024
Received: (qmail 11071 invoked from network); 16 Aug 2014 00:45:28 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI
	autolearn=ham version=3.3.2
Date: Sat, 16 Aug 2014 08:35:04 +0800
From: Han Pingtian <hanpt@linux.vnet.ibm.com>
To: zsh-workers@zsh.org
Subject: Re: zsh 5.0.5-dev-2
Message-ID: <20140816003504.GB17063@localhost.localdomain>
Mail-Followup-To: zsh-workers@zsh.org
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>
 <140815101701.ZM5288@torch.brasslantern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <140815101701.ZM5288@torch.brasslantern.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14081600-1344-0000-0000-00000380A309

On Fri, Aug 15, 2014 at 10:17:01AM -0700, Bart Schaefer wrote:
> 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?

I have tried PATH_MAX*3 and PATH_MAX*3 - 1, they both can fix the
buffer overflow here. I also tried PATH_MAX*2 + 1/2/3, they don't 
fix this problem.