This is the mail archive of the
glibc-bugs-regex@sourceware.org
mailing list for the glibc project.
[Bug regex/17070] New: regcomp with REG_EXTENDED uses unbounded CPU or RAM
- From: "konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs-regex at sourceware dot org
- Date: Thu, 19 Jun 2014 07:45:38 +0000
- Subject: [Bug regex/17070] New: regcomp with REG_EXTENDED uses unbounded CPU or RAM
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17070
Bug ID: 17070
Summary: regcomp with REG_EXTENDED uses unbounded CPU or RAM
Product: glibc
Version: 2.20
Status: NEW
Severity: normal
Priority: P2
Component: regex
Assignee: unassigned at sourceware dot org
Reporter: konstantin.s.serebryany at gmail dot com
CC: drepper.fsp at gmail dot com
[not sure how useful these reports are, but filing just in case.]
#include <regex.h>
int main(int argc, char **argv) {
regex_t r;
regcomp(&r,
#if 1
"([\\u]\\N|||){85,}[:ascii:]l[:(?!graph:]x?x)",
#else
"[(?{x<]})x{146}{,78}{,154}{,211}\\P{(?>^Latin}"
"x\\w\\p{^So}\\P{Alphabetic}[:punct:]\\P{^Mc}xxx)"
"[:alnum:]{-9,}[:blankcntrl:][:upperword:][:punct:]\\e",
#endif
REG_EXTENDED);
regfree(&r);
}
% gcc r1.c && ./a.out
The first pattern just never ends, most of the time is spent
in deep recursive call to calc_eclosure_iter
The second case is much worse -- it quickly eats all available RAM on the
machine,
doing tons of allocations here:
#1 0x00007ffff7a9cf95 in __GI___libc_malloc (bytes=968) at malloc.c:2924
#2 0x00007ffff7af1e3b in create_token_tree
#3 duplicate_tree
#4 0x00007ffff7af7f6f in parse_dup_op
#5 parse_expression
#6 0x00007ffff7af6470 in parse_branch
#7 0x00007ffff7af67be in parse_reg_exp
#8 0x00007ffff7af6cc0 in parse
#9 re_compile_internal
Checked with 2.15 and fresh trunk, tests were generated by regfuzz
--
You are receiving this mail because:
You are on the CC list for the bug.