From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29677 invoked by alias); 19 Jun 2014 05:53:32 -0000 Mailing-List: contact glibc-bugs-regex-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-regex-owner@sourceware.org Received: (qmail 29653 invoked by uid 48); 19 Jun 2014 05:53:29 -0000 From: "konstantin.s.serebryany at gmail dot com" To: glibc-bugs-regex@sourceware.org Subject: [Bug regex/17069] New: leak in regcomp Date: Thu, 19 Jun 2014 05:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: regex X-Bugzilla-Version: 2.20 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: konstantin.s.serebryany at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00010.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17069 Bug ID: 17069 Summary: leak in regcomp 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 regcomp has a memory leak. Present in ancient 2.15 and in fresh trunk. clang -fsanitize=3Daddress -g ./r.c && ASAN_OPTIONS=3Dfast_unwind_on_malloc= =3D0 ./a.out 1 =3D=3D1371=3D=3DERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x4943d9 in calloc #1 0x7fa25a3e57c3 in parse_bracket_exp glibc-trunk/posix/regcomp.c:3045 #2 0x7fa25a3e57c3 in parse_expression glibc-trunk/posix/regcomp.c:2265 #3 0x7fa25a3e9181 in parse_branch glibc-trunk/posix/regcomp.c:2193 #4 0x7fa25a3e9408 in parse_reg_exp glibc-trunk/posix/regcomp.c:2145 #5 0x7fa25a3ea156 in parse glibc-trunk/posix/regcomp.c:2114 #6 0x7fa25a3ea156 in re_compile_internal glibc-trunk/posix/regcomp.c:794 #7 0x7fa25a3ece0f in __regcomp glibc-trunk/posix/regcomp.c:501 #8 0x4b2c6e in main r.c:8 Valgrind sees it too:=20 gcc -std=3Dc99 -g ./r.c && valgrind --leak-check=3Dfull ./a.out 1 =3D=3D1895=3D=3D 32 bytes in 1 blocks are definitely lost in loss record 1 = of 1 =3D=3D1895=3D=3D at 0x4C2B1B8: calloc (vg_replace_malloc.c:618) =3D=3D1895=3D=3D by 0x4F145DE: parse_expression (regcomp.c:3057) =3D=3D1895=3D=3D by 0x4F1246F: parse_branch (regcomp.c:2170) =3D=3D1895=3D=3D by 0x4F127BD: parse_reg_exp (regcomp.c:2122) =3D=3D1895=3D=3D by 0x4F12CBF: re_compile_internal (regcomp.c:2091) =3D=3D1895=3D=3D by 0x4F16E7E: regcomp (regcomp.c:506) =3D=3D1895=3D=3D by 0x4005E9: main (r.c:8) Running this test with large number of iterations you can see the leak in '= top' #include #include int main(int argc, char **argv) { long n =3D argc =3D=3D 2 ? atol(argv[1]) : 1; for (long i =3D 0; i < n; i++) { regex_t r; regcomp(&r, "[^[][:alpha:][:up[^perword:]\\{-2(?>From glibc-bugs-regex-return-607-listarch-glibc-bugs-regex=sources.redhat.com@sourceware.org Thu Jun 19 07:45:44 2014 Return-Path: Delivered-To: listarch-glibc-bugs-regex@sources.redhat.com Received: (qmail 15040 invoked by alias); 19 Jun 2014 07:45:43 -0000 Mailing-List: contact glibc-bugs-regex-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-regex-owner@sourceware.org Delivered-To: mailing list glibc-bugs-regex@sourceware.org Received: (qmail 15014 invoked by uid 48); 19 Jun 2014 07:45:40 -0000 From: "konstantin.s.serebryany at gmail dot com" To: glibc-bugs-regex@sourceware.org Subject: [Bug regex/17070] New: regcomp with REG_EXTENDED uses unbounded CPU or RAM Date: Thu, 19 Jun 2014 07:45:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: regex X-Bugzilla-Version: 2.20 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: konstantin.s.serebryany at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00011.txt.bz2 Content-length: 2027 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 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.