GNU bug report logs - #34140
AddressSanitizer reported heap-buffer-overflow when ignoring case

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34140 in the body.
You can then email your comments to 34140 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hongxu Chen <leftcopy.chx <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: AddressSanitizer reported heap-buffer-overflow when ignoring case
Date: Sun, 20 Jan 2019 13:18:38 +0800

[Message part 1 (text/plain, inline)]

Hi,

    Latest `grep` (git commit 1019e6e) compiled with asan may cause a
heap-buffer-overflow when `-i` is specified.

    ./grep -i '\(\(\)*.\)*\(\)\(\)\1' /bin/chvt

=================================================================
==16206==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x602000000dd8 at pc 0x0000004b43a6 bp 0x7ffe385a7e50 sp 0x7ffe385a7600
READ of size 6 at 0x602000000dd8 thread T0
    #0 0x4b43a5 in __interceptor_memcmp.part.283
(/home/hongxu/FOT/grep-O0/install/bin/grep+0x4b43a5)
    #1 0x588bfc in proceed_next_node
/home/hongxu/FOT/grep-O0/lib/./regexec.c:1296:9
    #2 0x588bfc in set_regs /home/hongxu/FOT/grep-O0/lib/./regexec.c:1453
    #3 0x56ad33 in re_search_internal
/home/hongxu/FOT/grep-O0/lib/./regexec.c:864:10
    #4 0x56c11f in re_search_stub
/home/hongxu/FOT/grep-O0/lib/./regexec.c:425:12
    #5 0x56c92e in rpl_re_search
/home/hongxu/FOT/grep-O0/lib/./regexec.c:289:10
    #6 0x5146f2 in EGexecute /home/hongxu/FOT/grep-O0/src/dfasearch.c:357:19
    #7 0x51c9f7 in grepbuf /home/hongxu/FOT/grep-O0/src/grep.c:1395:29
    #8 0x51ad7f in grep /home/hongxu/FOT/grep-O0/src/grep.c:1526:23
    #9 0x51ad7f in grepdesc /home/hongxu/FOT/grep-O0/src/grep.c:1849
    #10 0x518df9 in main /home/hongxu/FOT/grep-O0/src/grep.c
    #11 0x7f6ab0c75b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #12 0x41b489 in _start
(/home/hongxu/FOT/grep-O0/install/bin/grep+0x41b489)

0x602000000dd8 is located 0 bytes to the right of 8-byte region
[0x602000000dd0,0x602000000dd8)
allocated by thread T0 here:
    #0 0x4db7c0 in realloc
(/home/hongxu/FOT/grep-O0/install/bin/grep+0x4db7c0)
    #1 0x566ee2 in re_string_allocate
/home/hongxu/FOT/grep-O0/lib/./regex_internal.c:168:32
    #2 0x566ee2 in re_search_internal
/home/hongxu/FOT/grep-O0/lib/./regexec.c:646
    #3 0x56c11f in re_search_stub
/home/hongxu/FOT/grep-O0/lib/./regexec.c:425:12

SUMMARY: AddressSanitizer: heap-buffer-overflow
(/home/hongxu/FOT/grep-O0/install/bin/grep+0x4b43a5) in
__interceptor_memcmp.part.283
Shadow bytes around the buggy address:
  0x0c047fff8160: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff8170: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff8180: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff8190: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff81a0: fa fa fd fa fa fa 00 06 fa fa fd fa fa fa fd fa
=>0x0c047fff81b0: fa fa fd fd fa fa fd fd fa fa 00[fa]fa fa fd fd
  0x0c047fff81c0: fa fa fd fa fa fa fd fd fa fa 00 00 fa fa fd fd
  0x0c047fff81d0: fa fa fd fa fa fa fd fa fa fa 00 00 fa fa fd fa
  0x0c047fff81e0: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff81f0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff8200: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==16206==ABORTING
[1]    16206 abort      ./grep -i '\(\(\)*.\)*\(\)\(\)\1' /bin/chvt


Best Regards,
Hongxu

[Message part 2 (text/html, inline)]

[chvt (application/octet-stream, attachment)]

Message #8 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Hongxu Chen <leftcopy.chx <at> gmail.com>
Cc: 34140 <at> debbugs.gnu.org
Subject: Re: AddressSanitizer reported heap-buffer-overflow when ignoring case
Date: Mon, 21 Jan 2019 11:28:23 -0800

Thanks for the bug report. I tracked it down to a read buffer overrun in glibc's 
regexec.c and filed a bug report with a fix here:

https://sourceware.org/bugzilla/show_bug.cgi?id=24114

glibc is frozen right now (it's just before the glibc 2.29 release), so most 
likely the bug fix will appear in glibc 2.30. I plan to propagate the fix into 
Gnulib (and therefore into grep) shortly after glibc 2.29 is released.

Message #11 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Hongxu Chen <leftcopy.chx <at> gmail.com>, 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Mon, 21 Jan 2019 16:38:20 -0800

On Mon, Jan 21, 2019 at 11:32 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Thanks for the bug report. I tracked it down to a read buffer overrun in glibc's
> regexec.c and filed a bug report with a fix here:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=24114
>
> glibc is frozen right now (it's just before the glibc 2.29 release), so most
> likely the bug fix will appear in glibc 2.30. I plan to propagate the fix into
> Gnulib (and therefore into grep) shortly after glibc 2.29 is released.

Thanks, Paul.
For the record, here's a small reproducer:

  printf xxxxxxxxxxxxxx |valgrind src/grep -i '\(\(\)*.\)*\1'

which induces this:

==10527== Invalid read of size 1
==10527==    at 0x483F0F5: bcmp (vg_replace_strmem.c:1113)
==10527==    by 0x420B96: proceed_next_node (regexec.c:1296)
==10527==    by 0x420B96: set_regs (regexec.c:1453)
==10527==    by 0x422956: re_search_internal (regexec.c:864)
==10527==    by 0x42700E: re_search_stub (regexec.c:425)
==10527==    by 0x42775F: rpl_re_search (regexec.c:289)
==10527==    by 0x405524: EGexecute (dfasearch.c:357)
==10527==    by 0x406B9F: grepbuf (grep.c:1395)
==10527==    by 0x407C5C: grep (grep.c:1567)
==10527==    by 0x407C5C: grepdesc (grep.c:1849)
==10527==    by 0x404277: grep_command_line_arg (grep.c:1891)
==10527==    by 0x404277: main (grep.c:2938)
==10527==  Address 0x4b0eabe is 0 bytes after a block of size 14 alloc'd
==10527==    at 0x483AD19: realloc (vg_replace_malloc.c:836)
==10527==    by 0x41A2F3: re_string_realloc_buffers (regex_internal.c:168)
==10527==    by 0x41AE0D: extend_buffers (regexec.c:4067)
==10527==    by 0x4218C2: get_subexp (regexec.c:2747)
==10527==    by 0x4218C2: transit_state_bkref.isra.0 (regexec.c:2566)
==10527==    by 0x421AD9: merge_state_with_log (regexec.c:2349)
==10527==    by 0x422747: check_matching (regexec.c:1139)
==10527==    by 0x422747: re_search_internal (regexec.c:805)
==10527==    by 0x42700E: re_search_stub (regexec.c:425)
==10527==    by 0x42775F: rpl_re_search (regexec.c:289)
==10527==    by 0x405524: EGexecute (dfasearch.c:357)
==10527==    by 0x406B9F: grepbuf (grep.c:1395)
==10527==    by 0x407C5C: grep (grep.c:1567)
==10527==    by 0x407C5C: grepdesc (grep.c:1849)
==10527==    by 0x404277: grep_command_line_arg (grep.c:1891)
==10527==    by 0x404277: main (grep.c:2938)

Message #14 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: arnold <at> skeeve.com
To: leftcopy.chx <at> gmail.com, eggert <at> cs.ucla.edu
Cc: 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Tue, 22 Jan 2019 01:44:13 -0700

If I may beg to differ, I see no reason that GNULIB can't be
ahead of GLIBC. In particular for the benefit of programs that use
it, like grep/sed/gawk.

If necessary, I can copy/paste the change from the bug report, but
it'd be nicer if you'd just push it to GNULIB.

Thanks,

Arnold

Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> Thanks for the bug report. I tracked it down to a read buffer overrun in glibc's 
> regexec.c and filed a bug report with a fix here:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=24114
>
> glibc is frozen right now (it's just before the glibc 2.29 release), so most 
> likely the bug fix will appear in glibc 2.30. I plan to propagate the fix into 
> Gnulib (and therefore into grep) shortly after glibc 2.29 is released.
>
>

Message #17 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: arnold <at> skeeve.com, leftcopy.chx <at> gmail.com
Cc: 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Tue, 22 Jan 2019 15:44:26 -0800

On 1/22/19 12:44 AM, arnold <at> skeeve.com wrote:
> If I may beg to differ, I see no reason that GNULIB can't be
> ahead of GLIBC.
The only reason is avoiding hassle: I'd have to decouple this gnulib 
file from glibc now (which requires changing some other administrative 
file), and then recouple it later. If this bug were important I'd be 
inclined to do the extra work - but is it that important?

Message #20 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: arnold <at> skeeve.com
To: leftcopy.chx <at> gmail.com, eggert <at> cs.ucla.edu, arnold <at> skeeve.com
Cc: 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Wed, 23 Jan 2019 00:08:40 -0700

Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 1/22/19 12:44 AM, arnold <at> skeeve.com wrote:
> > If I may beg to differ, I see no reason that GNULIB can't be
> > ahead of GLIBC.
> The only reason is avoiding hassle: I'd have to decouple this gnulib 
> file from glibc now (which requires changing some other administrative 
> file), and then recouple it later. If this bug were important I'd be 
> inclined to do the extra work - but is it that important?

If the time period between the bug fix and GNULIB getting updated is
short (for some definition of "short") then it's not that important.
If it drags out, it becomes a hassle.

Do you have an ETA on when the fix will get pushed to GNULIB?

Thanks,

Arnold

Message #23 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: arnold <at> skeeve.com, leftcopy.chx <at> gmail.com
Cc: 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Fri, 25 Jan 2019 16:24:09 -0800

On 1/22/19 11:08 PM, arnold <at> skeeve.com wrote:
> Do you have an ETA on when the fix will get pushed to GNULIB?

Glibc is scheduled for release on February 1, and I plan to update glibc 
and Gnulib soon after it's released (which may be a bit later than Feb. 1).

Message #26 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: arnold <at> skeeve.com
To: leftcopy.chx <at> gmail.com, eggert <at> cs.ucla.edu, arnold <at> skeeve.com
Cc: 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Sat, 26 Jan 2019 12:11:14 -0700

Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 1/22/19 11:08 PM, arnold <at> skeeve.com wrote:
> > Do you have an ETA on when the fix will get pushed to GNULIB?
>
> Glibc is scheduled for release on February 1, and I plan to update glibc 
> and Gnulib soon after it's released (which may be a bit later than Feb. 1).

Excellent. Thanks!

Arnold

Message #31 received at 34140-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: arnold <at> skeeve.com, leftcopy.chx <at> gmail.com
Cc: 34140-done <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Thu, 31 Jan 2019 13:34:53 -0800

On 1/25/19 4:24 PM, Paul Eggert wrote:
> On 1/22/19 11:08 PM, arnold <at> skeeve.com wrote:
>> Do you have an ETA on when the fix will get pushed to GNULIB?
>
> Glibc is scheduled for release on February 1, and I plan to update 
> glibc and Gnulib soon after it's released (which may be a bit later 
> than Feb. 1). 

This is done now and the fix is propagated into Gnulib and grep, so I'm 
marking the grep bug as done. If you're using a glibc version before 
glibc 2.30 (which will not be out for months) you may need to 
'./configure --with-included-regex' to get the fix.

Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Thu, 31 Jan 2019 16:22:05 -0600

On 01/31/2019 03:34 PM, Paul Eggert wrote:
> On 1/25/19 4:24 PM, Paul Eggert wrote:
>> On 1/22/19 11:08 PM, arnold <at> skeeve.com wrote:
>>> Do you have an ETA on when the fix will get pushed to GNULIB?
>>
>> Glibc is scheduled for release on February 1, and I plan to update 
>> glibc and Gnulib soon after it's released (which may be a bit later 
>> than Feb. 1). 
> 
> This is done now and the fix is propagated into Gnulib and grep, so I'm 
> marking the grep bug as done. If you're using a glibc version before 
> glibc 2.30 (which will not be out for months) you may need to 
> './configure --with-included-regex' to get the fix.

Will there be a new grep release soon?

  -- Bruce Dubbs
     linuxfromscratch.org

Message #37 received at 34140 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>, 34140 <at> debbugs.gnu.org
Subject: Re: bug#34140: AddressSanitizer reported heap-buffer-overflow when
 ignoring case
Date: Thu, 31 Jan 2019 15:10:55 -0800

On 1/31/19 2:22 PM, Bruce Dubbs wrote:
> Will there be a new grep release soon? 

I don't have any plans. This bug doesn't seem to be that urgent to fix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.