Bug 113421 - peek_token() uses uninitialized array element in posix/bug-regex20
Summary: peek_token() uses uninitialized array element in posix/bug-regex20
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-13 18:40 UTC by John Reiser
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-28 09:44:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Reiser 2004-01-13 18:40:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
Running testcase posix/bug-regex20, the code uses an uninitialized
array element.  The valgrind/memcheck complaint is

-----
==22450== Conditional jump or move depends on uninitialised value(s)
==22450==    at 0xD88A5D: peek_token (in /lib/i686/libc-2.3.2.so)
==22450==    by 0xD88EC8: parse_expression (in /lib/i686/libc-2.3.2.so)
==22450==    by 0xD88D8A: parse_branch (in /lib/i686/libc-2.3.2.so)
==22450==    by 0xD88BDD: parse_reg_exp (in /lib/i686/libc-2.3.2.so)
-----

The Insure++ complaint (in no-recompile mode) is
-----
[regcomp.c:765] (Thread 0) **READ_UNINIT_MEM(read)**
>> #ifdef DEBUG
 
  Reading uninitialized memory.
 
  Pointer : 0x4022001c
  In block: 0x4021ffe8 thru 0x4022001f (56 bytes)
                  block allocated at regex_internal.c, 155
       re_string_realloc_buffers()  regex_internal.c, 155
             re_string_construct()  regex_internal.c, 94
             re_compile_internal()  regcomp.c, 770
            __re_compile_pattern()  regcomp.c, 247
                            main()  bug-regex20.c, 247
 
  Stack trace where the error occurred:
                      peek_token()  regcomp.c, 765
                parse_expression()  regcomp.c, 1613
                    parse_branch()  regcomp.c, 2061
                   parse_reg_exp()  regcomp.c, 2006
                           parse()  regcomp.c, 1970
             re_compile_internal()  regcomp.c, 785
            __re_compile_pattern()  regcomp.c, 247
                            main()  bug-regex20.c, 247
-----



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

How reproducible:
Always

Steps to Reproduce:
1. Run internal testcase posix/bug-regex20 under a memory access checker.

Or: run under gdb, break at the 34-th call to re_realloc() within
re_string_realloc_buffers() at regex_internal.c:154, set a
read-and-write watchpoint on the 13th 4-byte element of the 14-element
array, and notice that the first access is a read ['cmpl' on i386]
instead of a write.  [See Additional Information below.]
    

Actual Results:  Complaints about use of uninit value, as noted in
Description.

Expected Results:  No use of uninit value.

Additional info:

The relevant raw_mbs is "^x\\\\y\\{6\\}z\\+" which is a 13-byte string
-----
  ^ x \ \ y \ { 6 \ } z \ +
-----
The uninit element is the last element of a 14-element array allocated
by re_string_realloc_buffers() on the 34-th time at
regex_internal.c:154 calling re_realloc().

Comment 1 Jakub Jelinek 2004-01-13 23:36:30 UTC
Thanks.
http://sources.redhat.com/ml/libc-hacker/2004-01/msg00054.html

Comment 2 Ulrich Drepper 2004-09-28 09:44:37 UTC
Assume fixed in current release.


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