Bug 113421 - peek_token() uses uninitialized array element in posix/bug-regex20
peek_token() uses uninitialized array element in posix/bug-regex20
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-13 13:40 EST by John Reiser
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-28 05:44:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2004-01-13 13:40:15 EST
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 18:36:30 EST
Thanks.
http://sources.redhat.com/ml/libc-hacker/2004-01/msg00054.html
Comment 2 Ulrich Drepper 2004-09-28 05:44:37 EDT
Assume fixed in current release.

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