This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12424] New: strtod() reads past the string end
- From: "yeti at physics dot muni.cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 20 Jan 2011 22:57:37 +0000
- Subject: [Bug libc/12424] New: strtod() reads past the string end
- Auto-submitted: auto-generated
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.