From owner-freebsd-stable@FreeBSD.ORG Thu Nov 8 18:32:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88AD5F80 for ; Thu, 8 Nov 2012 18:32:40 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id 185C18FC0C for ; Thu, 8 Nov 2012 18:32:39 +0000 (UTC) Received: from charlemagne.boland.org (37-251-66-226.FTTH.ispfabriek.nl [37.251.66.226]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA8IW1Ja026960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 19:32:02 +0100 (CET) (envelope-from boland37@xs4all.nl) Message-ID: <509BFAA1.8000201@xs4all.nl> Date: Thu, 08 Nov 2012 19:32:01 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jan Mikkelsen Subject: Re: dc(1) fails with "big number failure" on 2^64 References: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> In-Reply-To: <2ABD38E2-A9F7-4AD3-9364-B21F6566F7CB@transactionware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:32:40 -0000 On 11/08/2012 03:06, Jan Mikkelsen wrote: > Hi, > > I am seeing this in dc: > > janm@gray: dc $ dc > 18446744073709551616 18446744073709551616 / ps > dc: big number failure 306b06b: No such file or directory > > That number is 2^64. The error is coming from BN_check in bdiv(), which is complaining about the number at the top of the stack being uninitialised. Looking at the data, after the second pop in bdiv() in bdata.c, b->number->d[b->number->top - 1] == 0. After a while poking around in a debugger, it looks like the first word of the second number (a->number->d) is being allocated at the same location as the last word of the second number, it gets zeroed, and then looks uninitialised. > > All of this seems to be happening in the BN_* routines in openssl. > > I am seeing this on my builds for 9.1-RC3 and 9.0-p3, as well as the CDROM shell on the 9.1-RC3 ISO, so I'm pretty sure it isn't my build process or compiler flags. I have checked an OpenBSD 5.2 installation, and it works fine. > > Can anyone confirm this? Am I just seeing things? Is there an obvious fix? No fix, but I see a problem in the BN_add_word function in /usr/src/crypto/openssl/crypto/bn/bn_word.c /* Only expand (and risk failing) if it's possibly necessary */ if (((BN_ULONG)(a->d[a->top - 1] + 1) == 0) && (bn_wexpand(a,a->top+1) == NULL)) return(0); This can't possibly work, since it never calls bn_wexpand if, for example, you add 6 to the number 18446744073709551610 Cheers Michiel