------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1018
Summary: Stack overflow (not buffer overflow)
Product: PCRE
Version: 7.8
Platform: Other
OS/Version: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Code
AssignedTo: ph10@???
ReportedBy: njohnson@???
CC: pcre-dev@???, njohnson@???
This is something I ran across while using grep a few weeks ago. It's a basic
stack overflow (can't grow the stack any farther), but it takes a relatively
simple file and regex to reproduce it:
n4g-[ src ]-> ruby -e 'print ("a b c d e f g\n"*1000)' > repro.txt
n4g-[ src ]-> grep -P "([\n]|.)*" repro.txt
Segmentation fault
n4g-[ src ]-> grep --version
GNU grep 2.5.4
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
n4g-[ src ]-> pkg-config --modversion libpcre
7.8
Here's some valgrind output as well:
n4g-[ src ]-> valgrind.bin --tool=memcheck grep -P "([\n]|.)*" repro.txt
==2811== Memcheck, a memory error detector
==2811== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2811== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright
info
==2811== Command: grep -P ([\\n]|.)* repro.txt
==2811==
==2811== Stack overflow in thread 1: can't grow stack to 0xbe5defe0
==2811==
==2811== Process terminating with default action of signal 11 (SIGSEGV)
==2811== Access not within mapped region at address 0xBE5DEFE0
==2811== at 0x46D8784: match (pcre_exec.c:1337)
==2811== If you believe this happened as a result of a stack
==2811== overflow in your program's main thread (unlikely but
==2811== possible), you can try to increase the size of the
==2811== main thread stack using the --main-stacksize= flag.
==2811== The main thread stack size used in this run was 8388608.
==2811== Stack overflow in thread 1: can't grow stack to 0xbe5def6c
==2811==
==2811== Process terminating with default action of signal 11 (SIGSEGV)
==2811== Access not within mapped region at address 0xBE5DEF6C
==2811== at 0x401F41C: _vgnU_freeres (vg_preloaded.c:58)
==2811== If you believe this happened as a result of a stack
==2811== overflow in your program's main thread (unlikely but
==2811== possible), you can try to increase the size of the
==2811== main thread stack using the --main-stacksize= flag.
==2811== The main thread stack size used in this run was 8388608.
==2811==
==2811== HEAP SUMMARY:
==2811== in use at exit: 60,964 bytes in 434 blocks
==2811== total heap usage: 1,397 allocs, 963 frees, 103,249 bytes allocated
==2811==
==2811== LEAK SUMMARY:
==2811== definitely lost: 0 bytes in 0 blocks
==2811== indirectly lost: 0 bytes in 0 blocks
==2811== possibly lost: 0 bytes in 0 blocks
==2811== still reachable: 60,964 bytes in 434 blocks
==2811== suppressed: 0 bytes in 0 blocks
==2811== Rerun with --leak-check=full to see details of leaked memory
==2811==
==2811== For counts of detected and suppressed errors, rerun with: -v
==2811== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 11)
Segmentation fault
... and here's a basic back trace:
in match() - pcre_exec.c:1337
in match() - pcre_exec.c:1323
... (above stack frame repeated 20K+ times) ...
in match() - pcre_exec.c:1186
in pcre_exec() - pcre_exec.c:4846
It seems like the main problem is centered around the \n newlines. The second
argument to the OR ("." in the example) merely needs to match existing
characters in the file. A similar repro file with only "a"s and a regex like
"([\n]|a)*" also triggers the same crash.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
