From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13123 invoked by alias); 27 Feb 2012 16:23:05 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30276 Received: (qmail 21373 invoked from network); 27 Feb 2012 16:22:54 -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 autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at leonweber.de does not designate permitted sender hosts) Date: Mon, 27 Feb 2012 17:22:51 +0100 From: Leon Weber To: zsh-workers@zsh.org Subject: Integer overflow during brace expansion Message-ID: <20120227162251.GA17559@zaphod.q-ix.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, When parsing and expanding 'dotdot' type brace expressions (e.g. {1..3}), zsh can encounter integer overflows because the range start and end values are stored in two integers without proper bounds checking (rstart and rend in glob.c:2092). Particularly, this happens when one of the range boundaries is <=-2147483648 or >=2147483648, like in this example: > zsh% echo {-2147483648..-2147483646} This will cause zsh to eat up 100% CPU iterating through the loop declared in line 2147 in glob.c. In that loop, rend is decreased until it underflows. In the third and fourth iterations, we have these conditions: // // third iteration // > Breakpoint 15, xpandbraces (list=0x7ffff7fee340, np=0x7fffffffd460) at glob.c:2149 > 2149 p = dupstring(str3); > (gdb) p rend > $56 = -2147483648 > (gdb) p rstart > $57 = -2147483648 > (gdb) cont > Continuing. // // fourth iteration // > Breakpoint 15, xpandbraces (list=0x7ffff7fee340, np=0x7fffffffd460) at glob.c:2149 > 2149 p = dupstring(str3); > (gdb) p rend > $58 = 2147483647 > (gdb) p rstart > $59 = -2147483648 This gdb output clearly shows that rend has underflown and is now at the far positive end of the valid integer values. zsh will keep iterating over that loop and decreasing rend for a really long time. For comparison, a bash shell handles this correctly: > bash$ echo {-2147483648..-2147483646} > -2147483648 -2147483647 -2147483646 I have been able reproduce this issue on Ubuntu x86_64 and x86 using zsh 4.3.10, 4.3.11, and git revision db7d0ac34143ed2378c2fd98845b2ae5eaaf6bbb. All mentioned line numbers reference to git revision db7d0ac34143ed2378c2fd98845b2ae5eaaf6bbb. Regards, -- Leon. PS: I already posted this on the sourceforge bug tracker before finding out that's not in use. Perhaps it would be good to note this details somewhere visible along with some hints on where to really report bugs, since the sf tracker is the first google hit on 'zsh bugs' and this mailing list doesn't show up anywhere near that. --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9LrdsACgkQmxj00I4E1/xcrACeJdPiZbZwr00WXEMfTXgGrp3u AxUAnjyP2uw+FQVrrYWtDrjYfrNae+tv =jvmG -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm--