Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Dan Douglas <ormaaj@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Integer Overflow in braces
Date: Tue, 18 Aug 2015 08:12:39 -0500
Lines: 33
Approved: bug-bash@gnu.org
Message-ID: <mailman.8517.1439903573.904.bug-bash@gnu.org>
References: <CABq52TYThGj9OtBn3xTti5scmA=WdnS7ULw3G6GMayPK6WR0+w@mail.gmail.com> <5768562.ErHXazUaoC@smorgbox> <20150818130433.GF4309@eeg.ccf.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7Bit
Cc: Greg Wooledge <wooledg@eeg.ccf.org>, Pasha K <pashakravtsov@gmail.com>
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: KMail/5.0.41 alpha1 (Linux/4.2.0-rc7; KDE/5.14.0; x86_64; ; )
In-Reply-To: <20150818130433.GF4309@eeg.ccf.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:11364

On Tuesday, August 18, 2015 09:04:33 AM Greg Wooledge wrote:
> On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
> > IMHO the issue of whether the integer is allowed to overflow is separate 
from 
> > the question of whether the resulting expansion is "too big". Code that 
does 
> > an `eval "blah{0..$n}"` is reasonably common and not necessarily stupid. 
> 
> Yes, that's fine.  But I don't actually understand what kind of overflow
> Pasha K was actually trying to test for.  He/she mentioned "nelem", which
> only appears in two places in the bash source code: once in indexed
> arrays, and once in associative arrays.  But there were no arrays in
> the script being executed.
> 
> {0..9999999999999999} should produce an error because it runs out of
> memory.  So I would expect to see a malloc failure, or something similar.
> If Pasha is saying that an integer overflow occurs before the malloc
> failure, then that may or may not be interesting to Chet.  If it crashes
> bash, then it's not interesting to me, because the inevitable malloc
> failure would have crashed it if the overflow didn't.  It only becomes
> interesting to me if the integer overflow causes some weird behavior to
> happen BEFORE bash crashes.
> 

Actually I think I spoke too soon. There's already some considerable logic in 
braces.c to check for overflow (e.g. around braces.c:390 shortly after 
declaration of the int). Looks like there were some changes in this code last 
year to "beef it up" a bit. (see commit 
67440bc5959a639359bf1dd7d655915bf6e9e7f1). I suspect this is probably fixed in 
devel.
-- 
Dan Douglas