From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33366-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 19664 invoked by alias); 6 Oct 2014 14:09:16 -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: 33366
Received: (qmail 18408 invoked from network); 6 Oct 2014 14:09:04 -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,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-AuditID: cbfec7f5-b7f776d000003e54-2f-5432a27d6c32
Date: Mon, 06 Oct 2014 15:09:00 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: Buffer overflow with long fd numbers in redirects
Message-id: <20141006150900.4df5e556@pwslap01u.europe.root.pri>
In-reply-to:
 <CAHYJk3QeCiKGuohbduaFa9cct48oL4c2+weEQKsWpr91EM_YkQ@mail.gmail.com>
References: <CAHYJk3QeCiKGuohbduaFa9cct48oL4c2+weEQKsWpr91EM_YkQ@mail.gmail.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4Nd3aRUYhBhMuiVscbH7I5MDoserg
	B6YAxigum5TUnMyy1CJ9uwSujNfbWhkLelgrNj6fxN7A2MbSxcjBISFgIrHnRVoXIyeQKSZx
	4d56ti5GLg4hgaWMEr+2TmCEcJYzSRw/f4MRpIpFQFXi+49J7CA2m4ChxNRNs8HiIkDx5u//
	WEBsYQE7iTeXZjCB2LwC9hKvXrxlBrE5BYIl/v2CmCMkECDRte4X2Bx+AX2Jq38/MUFcYS8x
	88oZRoheQYkfk++BzWQW0JLYvK2JFcKWl9i85i3zBEaBWUjKZiEpm4WkbAEj8ypG0dTS5ILi
	pPRcI73ixNzi0rx0veT83E2MkBD8uoNx6TGrQ4wCHIxKPLyROwxDhFgTy4orcw8xSnAwK4nw
	ms8zChHiTUmsrEotyo8vKs1JLT7EyMTBKdXA6Jz1/Yoil6iI2UbtMwu1tmi8jDzSHtqenbix
	deGedT/mPDNPfXOb4/vfGw65eXsnJi++olekxdlwn0PCakl74oY0vzUOrgVPy4638IpyL+Ca
	PSMiud98b7Cd778HewzfTQ1vZ5E4NX2LQsnD9WXZa1ZGe4h+fDA3sa/nWtPaghaJT6yT71Yw
	KbEUZyQaajEXFScCAFHGrWcfAgAA

On Mon, 06 Oct 2014 16:00:44 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> Obviously anything over 999 will not fit in fdstr[]. I just checked
> and it appears we do not use snprintf anywhere, is this for any
> particular reason?

I think the shell's been around longer than snprintf has been
widespread.  It will need checking in configure and variant code; the
latter makes the shell less safe overall.

> The patch below just changes the array to [64], it
> should be some time before any system uses a 256-bit type for fds. If
> you guys have another preference for solving this, let me know

Shouldn't DIGBUFSIZE work?

pws