Bug 113425 - peek_token_bracket() uses uninitialized byte in posix/bug-regex22
peek_token_bracket() uses uninitialized byte in posix/bug-regex22
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 14:55 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:45:56 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 14:55:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
Testcase posix/bug-regex22 uses an uninitialized byte.  The Insure++
report is
-----
[regcomp.c:1900] (Thread 0) **READ_UNINIT_MEM(read)**
>>       c2 = re_string_peek_byte (input, 1);
 
  Reading uninitialized memory.
 
  Pointer : 0x4021ebe2
  In block: 0x4021ebe0 thru 0x4021ebe2 (3 bytes)
                  block allocated at regex_internal.c, 169
       re_string_realloc_buffers()  regex_internal.c, 169
             re_string_construct()  regex_internal.c, 94
             re_compile_internal()  regcomp.c, 770
            __re_compile_pattern()  regcomp.c, 247
                            main()  bug-regex22.c, 100
 
  Stack trace where the error occurred:
              peek_token_bracket()  regcomp.c, 1900
               parse_bracket_exp()  regcomp.c, 2978
                parse_expression()  regcomp.c, 2133
                    parse_branch()  regcomp.c, 2054
                   parse_reg_exp()  regcomp.c, 2006
                           parse()  regcomp.c, 1970
             re_compile_internal()  regcomp.c, 785
            __re_compile_pattern()  regcomp.c, 247
                            main()  bug-regex22.c, 100
-----


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

How reproducible:
Always

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

Or, run under gdb with a breakpoint at regex_internal.c:171 [just
after the lexically-last call to re_realloc() in
re_string_realloc_buffers()].  The 7th time that the breakpoint is
hit, put a read-and-write watchpoint on the last allocated byte, and
notice that the first access is a read-and-eventual-compare with ':',
instead of a write.    

Actual Results:  The uninit byte at the end of the array is compared
with ':'.

Expected Results:  No use of any uninit byte.

Additional info:

At the use of the uninit byte:
-----
(gdb) x/12i $pc
0x400ec578 <peek_token_bracket+184>:    movzbl 0x1(%edx,%eax,1),%ecx
0x400ec57d <peek_token_bracket+189>:    mov    $0x2,%edx
0x400ec582 <peek_token_bracket+194>:    movzbl %cl,%eax
0x400ec585 <peek_token_bracket+197>:    mov    %cl,(%esi)
0x400ec587 <peek_token_bracket+199>:    cmp    $0x3a,%eax
0x400ec58a <peek_token_bracket+202>:
    je     0x400ec5bd <peek_token_bracket+253>
0x400ec58c <peek_token_bracket+204>:    cmp    $0x3a,%eax
0x400ec58f <peek_token_bracket+207>:
    jg     0x400ec5b2 <peek_token_bracket+242>
0x400ec591 <peek_token_bracket+209>:    cmp    $0x2e,%eax
0x400ec594 <peek_token_bracket+212>:
    je     0x400ec5ac <peek_token_bracket+236>
0x400ec596 <peek_token_bracket+214>:    movb   $0x1,0x4(%esi)
0x400ec59a <peek_token_bracket+218>:    movzbl 0xfffffff7(%ebp),%edx
(gdb) p/c 0x3a
$17 = 58 ':'
(gdb) p/x $edx
$18 = 0x1
(gdb) p/x $eax
$19 = 0x4021ebe0
(gdb) x/s $eax
0x4021ebe0:      "[[\004@"
(gdb) bt
#0  gdb_break_here () at chap0.S:70
#1  0x400ec578 in peek_token_bracket (token=0xbffff110, input=0xbffff144,
    syntax=2145052) at regcomp.c:1900
#2  0x400e1449 in parse_bracket_exp (regexp=0xbffff144, dfa=0x40275438,
    token=0xbffff110, syntax=2145052, err=0xbffff140) at regcomp.c:2978
#3  0x400e0d69 in parse_expression (regexp=0xbffff144, preg=0x20bb1c,
    token=0xbffff110, syntax=2145052, nest=0, err=0xbffff140) at
regcomp.c:2133
#4  0x400e076e in parse_branch (regexp=0xbffff144, preg=0xbffff2ec,
    token=0xbffff110, syntax=2145052, nest=0, err=0xbffff140) at
regcomp.c:2054
#5  0x400e061e in parse_reg_exp (regexp=0xbffff144, preg=0xbffff2ec,
    token=0xbffff110, syntax=2145052, nest=0, err=0xbffff140) at
regcomp.c:2006
#6  0x400e0565 in parse (regexp=0xbffff144, preg=0xbffff2ec,
    syntax=3221221648, err=0xbffff140) at regcomp.c:1970
#7  0x400ddd6c in re_compile_internal (preg=0xbffff2ec,
    pattern=0x804889f "[[:DIGIT:]]", length=2, syntax=2145052) at
regcomp.c:785
#8  0x400dd296 in __re_compile_pattern (pattern=0x4021ebe0 "[[\004@",
    length=1075964896, bufp=0x1) at regcomp.c:247
#9  0x080485f9 in main () at bug-regex22.c:100
#10 0x40040760 in __libc_start_main (main=0x80484d0 <main>, argc=1,
    ubp_av=0xbffff3a0, init=0x8048770 <__libc_csu_init>, fini=0xbffff30c,
    rtld_fini=0, stack_end=0x1) at ../sysdeps/generic/libc-start.c:205
-----

At the allocation of the 3-byte array, the 7th hit of the breakpoint:
-----
Breakpoint 2, re_string_realloc_buffers (pstr=0xbffff144, new_buf_len=3)
    at regex_internal.c:171
171           if (BE (new_array == NULL, 0))
$16 = 0x4021ebe0
(gdb) bt
#0  re_string_realloc_buffers (pstr=0xbffff144, new_buf_len=3)
    at regex_internal.c:171
#1  0x400eb363 in re_string_construct (pstr=0xbffff144,
    str=0x804889f "[[:DIGIT:]]", len=3, trans=0xbffff1ec "", icase=0,
    dfa=0x40275438) at regex_internal.c:94
#2  0x400ddd3a in re_compile_internal (preg=0xbffff144,
    pattern=0x804889f "[[:DIGIT:]]", length=2, syntax=2145052) at
regcomp.c:770
#3  0x400dd296 in __re_compile_pattern (pattern=0x4021ebe0
"\231&#65533;\004@",
    length=1075964896, bufp=0x0) at regcomp.c:247
#4  0x080485f9 in main () at bug-regex22.c:100
#5  0x40040760 in __libc_start_main (main=0x80484d0 <main>, argc=1,
    ubp_av=0xbffff3a0, init=0x8048770 <__libc_csu_init>, fini=0xbffff30c,
    rtld_fini=0, stack_end=0x0) at ../sysdeps/generic/libc-start.c:205
-----
Comment 1 Jakub Jelinek 2004-01-13 18:36:53 EST
Thanks.
http://sources.redhat.com/ml/libc-hacker/2004-01/msg00054.html
Comment 2 Ulrich Drepper 2004-09-28 05:45:56 EDT
Assume fixed in current release.

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