Bug 141000 - strtold uses uninitialized array element
strtold uses uninitialized array element
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-11-27 14:40 EST by John Reiser
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 2.3.3-87
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 12:26:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Reiser 2004-11-27 14:40:15 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
strtold("42.00000000000000000001", NULL)
uses an unintialized array element.  [There are 19 zeroes betweeen the
decimal point and the '1' in the first argument.]  The uninit is
fetched at
          n0 = num[densize];
with 3==densize.  The 'while' loop at line 1507 is skipped (the
condition is false the first and only time), then
          for (i = densize; num[i] == 0 && i >= 0; --i)
          return round_and_return (retval, exponent - 1, negative,
                                   quot, BITS_PER_MP_LIMB - 1 - used,
                                   more_bits || i >= 0);

The condition "num[i] == 0" uses the uninit value num[densize].  The
result is an unpredictable value in "i", so the round_and_return can
perform a bad computation.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.gcc -std=c99 -g bug.c; valgrind --tool=memcheck ./a.out
#include <stdlib.h>
#include <stdio.h>

        printf("%Lg\n", strtold("42.00000000000000000001", NULL));
        return 0;

Actual Results:  ==17999== Memcheck, a memory error detector for
==17999== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==17999== Using valgrind-2.2.0, a program supervision framework for
==17999== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==17999== For more details, rerun with: -v
==17999== Conditional jump or move depends on uninitialised value(s)
==17999==    at 0x7B568F: __GI_____strtold_l_internal (in
==17999==    by 0x7AF0D6: strtold (in /lib/tls/libc-2.3.3.so)
==17999==    by 0x80483CA: main (bug.c:7)

Expected Results:  No complaints from valgrind.

Additional info:

This testcase appears in stdlib/tst-strtod.c.  Please consider running
valgrind on the glibc testcases.  (Have someone in the EU run them, if
necessary.  [I used my own memory checker, then verified that valgrind
would reproduce the complaint.])
Comment 1 Jakub Jelinek 2004-11-29 06:58:07 EST

Fedora Core 3 includes valgrind and you can run it anywhere, not just in EU.
I have ran valgrind on glibc testsuite a few months ago and fixed what I saw,
am doing it now again.  Hope I won't spend too much time on false positives.
Comment 2 John Reiser 2004-11-29 15:30:50 EST
"I have ran valgrind on glibc testsuite a few months ago ..."  Thank you!  This
bug #141000 and bug #141137 are the ones I found this time.  After the batch of
several such bugs in spring 2003 (bug #88052, etc.) I noticed that the following
major OS releases had very few, which suggested the possibility that glibc had
begun to use a memory access checker.  So this strtold case was a surprise.

It seems that valgrind is a new package in FC3, and had been barred from
previous OS releases because of US patent issues (or FUD).  Did these get
resolved definitively?
Comment 3 Jakub Jelinek 2004-12-03 12:26:48 EST
This should be fixed in glibc-2.3.3-87 in rawhide.

Note You need to log in before you can comment on or make changes to this bug.