This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12424] New: strtod() reads past the string end


http://sourceware.org/bugzilla/show_bug.cgi?id=12424

           Summary: strtod() reads past the string end
           Product: glibc
           Version: 2.13
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: yeti@physics.muni.cz


Created attachment 5204
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5204
test case

glibc checked out at 2011-01-20 approx. 20:00 UTC
build/host/target triplet (the same): x86_64-unknown-linux-gnu
configure options: only --prefix
uname -a: Linux smut 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC
2010 x86_64 x86_64 x86_64 GNU/Linux
gcc: gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)
ld: GNU ld version 2.20.51.0.7-6.fc14 20100318

Running strtod() on a string that consists only of "I" or "N" causes a read
past the end of the string somewhere within strncasecmp_l().  More precisely,
this is reported by valgrind and I don't understand the assembler code but it
seems real to me (see the log below, namely the second read).

A test case it attached.  Compiled

gcc -o strtod strtod.c

and executed

valgrind ./strtod

produces

==15770== Memcheck, a memory error detector
==15770== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==15770== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==15770== Command: ./strtod
==15770== 
p's address: 0x4f98040
==15770== Invalid read of size 8
==15770==    at 0x4C8D40F: __GI___strncasecmp_l (strcmp.S:213)
==15770==    by 0x4C45598: ____strtod_l_internal (strtod_l.c:553)
==15770==    by 0x4005D3: main (in /home/yeti/C/strtod)
==15770==  Address 0x4f98040 is 0 bytes inside a block of size 2 alloc'd
==15770==    at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==15770==    by 0x4C87331: strdup (strdup.c:43)
==15770==    by 0x4005A5: main (in /home/yeti/C/strtod)
==15770== 
==15770== Invalid read of size 8
==15770==    at 0x4C8D417: __GI___strncasecmp_l (strcmp.S:215)
==15770==    by 0x4C45598: ____strtod_l_internal (strtod_l.c:553)
==15770==    by 0x4005D3: main (in /home/yeti/C/strtod)
==15770==  Address 0x4f98048 is 6 bytes after a block of size 2 alloc'd
==15770==    at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==15770==    by 0x4C87331: strdup (strdup.c:43)
==15770==    by 0x4005A5: main (in /home/yeti/C/strtod)
==15770== 
==15770== 
==15770== HEAP SUMMARY:
==15770==     in use at exit: 0 bytes in 0 blocks
==15770==   total heap usage: 1 allocs, 1 frees, 2 bytes allocated
==15770== 
==15770== All heap blocks were freed -- no leaks are possible
==15770== 
==15770== For counts of detected and suppressed errors, rerun with: -v
==15770== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

(similarly for "N" in the source).

The string in the test case is dynamically allocated as a static string
probably appears in a sufficiently long readable section and produces no error.

It boils down to

STRNCASECMP (cp, L_("inf"), 3)

and

STRNCASECMP (cp, L_("nan"), 3)

in stdlib/strtod_l.c but somehow I am not able to reproduce it using
strncasecmp().

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]