https://sourceware.org/bugzilla/show_bug.cgi?id=10844 Gabriel Ravier <gabravier at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gabravier at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30833 Asmita <aasmita at ucdavis dot edu> <aasmita at ucdavis dot edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aasmita at ucdavis dot edu, | |yaroslav.oliinyk at netrise dot io -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30833 Bug ID: 30833 Summary: Segmentation fault in glibc 2.35, regcomp.c Product: glibc Version: 2.35 Status: UNCONFIRMED Severity: minor Priority: P2 Component: regex Assignee: unassigned at sourceware dot org Reporter: aasmita at ucdavis dot edu CC: drepper.fsp at gmail dot com Target Milestone: --- Created attachment 15103 --> https://sourceware.org/bugzilla/attachment.cgi?id=15103&action=edit It contains doc with details about the bug, the pattern that caused bug, corresponding screenshot. Version - Glibc 2.35 , was also reproducible in Glibc 2.38 Machine on which it was tested - `Uname -a` : Linux xxxx 5.19.0-45-generic #46~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 15:06:04 UTC 20 x86_64 x86_64 x86_64 GNU/Linux ( Was also reproducible on a debian based system). Note : Both Glibc 2.35 and 2.38 were compiled from the source code. (And was also tested with the one that came with distro. Issue was found in both) Issue : In regcomp() denial of service (DoS) by stack exhaustion. Triggers deep recursion that causes stack exhaustion. It’s similar to CVE-2010-4051 and it occurred in these latest glibc versions as well. Two types of pattern that caused the issue are : 1st pattern : long repeated ‘(((((((((((.........” and 2nd pattern : “/????{,29999}}” It leads to deep recursion causing stack exhaustion and hence Segmentation fault. Note : This work is done together with Yaroslav Oliinyk ( yaroslav.oliinyk@netrise.io) while doing my internship at Netrise -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=20095 Alexander Kernozhitsky <sh200105 at mail dot ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sh200105 at mail dot ru -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=20095 --- Comment #5 from Jonathan Wakely <jwakely.gcc at gmail dot com> --- (In reply to Adhemerval Zanella from comment #4) > Is this code really being tested by GNU grep? No idea - I grepped the grep code for cases of '++' and found those tests, I don't know if they're actually run or not. FWIW, Solaris 2.11 and AIX 7.3 both have the same behaviour for "a++" jwakely@gcc-solaris11:~$ /usr/xpg4/bin/grep -E a++ <<< a a $ /usr/bin/grep -E a++ <<< a a So maybe POSIX says it's undefined to allow for this traditional/common behaviour. Glibc's support for it seems poor though, given the memory exhaustion problems. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=20095 Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adhemerval.zanella at linaro dot o | |rg --- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> --- I am not sure who exactly GNU grep handles this since it also uses gnulib regex code. Is this code really being tested by GNU grep? I deleted the fil, make check, and it seems not to affect the test's outcome. I also tried to sync with gnulib master, but it also does not help. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=20095 Jonathan Wakely <jwakely.gcc at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwakely.gcc at gmail dot com --- Comment #3 from Jonathan Wakely <jwakely.gcc at gmail dot com> --- This behaviour can rapidly exhaust memory (Bug 25814, Bug 28864, Bug 20095 , Bug 29642), which seems unhelpful when ".++" is not even a valid regex. POSIX says it's undefined: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_06 Why doesn't regcomp just fail to compile it with REG_BADRPT? Similarly for ".**" etc. GNU grep seems to have tests for these that expect BADRPT: https://git.savannah.gnu.org/cgit/grep.git/tree/tests/tests?h=v3.11#n234 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29642 --- Comment #3 from Jonathan Wakely <jwakely.gcc at gmail dot com> --- Which seems to be a dup of PR 20095 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28864 Jonathan Wakely <jwakely.gcc at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwakely.gcc at gmail dot com --- Comment #2 from Jonathan Wakely <jwakely.gcc at gmail dot com> --- This seems to be a dup of PR 20095 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29642 Jonathan Wakely <jwakely.gcc at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwakely.gcc at gmail dot com --- Comment #2 from Jonathan Wakely <jwakely.gcc at gmail dot com> --- Looks like a dup of PR 28864 -- You are receiving this mail because: You are on the CC list for the bug.
[-- Attachment #1: Type: text/plain, Size: 413 bytes --] **I am looking for a possible partnership with a business or individual in your country so that I can make some investments there due to the prolonged civil war in my country, now the earthquake in Syria. I wish to relocate my investment capital to your country, any viable investment idea you suggest to me will be considered.* *Kindly, reply for us to discuss this further. Regards* *Al.Nabil, 69 years old.*
https://sourceware.org/bugzilla/show_bug.cgi?id=11053 --- Comment #26 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- The release/2.34/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=86a701a20479dfbc23540b3143fd5b28660a2447 commit 86a701a20479dfbc23540b3143fd5b28660a2447 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Tue Sep 21 07:47:45 2021 -0700 regex: copy back from Gnulib Copy regex-related files back from Gnulib, to fix a problem with static checking of regex calls noted by Martin Sebor. This merges the following changes: * New macro __attribute_nonnull__ in misc/sys/cdefs.h, for use later when copying other files back from Gnulib. * Use __GNULIB_CDEFS instead of __GLIBC__ when deciding whether to include bits/wordsize.h etc. * Avoid duplicate entries in epsilon closure table. * New regex.h macro _REGEX_NELTS to let regexec say that its pmatch arg should contain nmatch elts. Use that for regexec, instead of __attr_access (which is incorrect). * New regex.h macro _Attr_access_ which is like __attr_access except portable to non-glibc platforms. * Add some DEBUG_ASSERTs to pacify gcc -fanalyzer and to catch recently-fixed performance bugs if they recur. * Add Gnulib-specific stuff to port the dynarray- and lock-using parts of regex code to non-glibc platforms. * Fix glibc bug 11053. * Avoid some undefined behavior when popping an empty fail stack. (cherry picked from commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82) -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=25322 --- Comment #80 from bh ta <bhtrananh8 at gmail dot com> --- Thank you for update. https://otomg.vn -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29642 --- Comment #1 from jy l <linjy0410 at gmail dot com> --- Created attachment 14373 --> https://sourceware.org/bugzilla/attachment.cgi?id=14373&action=edit regex DOS poc please be caution to run it since it might exhaust all the memory within few seconds -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29642 Bug ID: 29642 Summary: `regcomp` with multiple adjacent plus sign would exhaust memory quickly Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: regex Assignee: unassigned at sourceware dot org Reporter: linjy0410 at gmail dot com CC: drepper.fsp at gmail dot com Target Milestone: --- Hi! We found that in the latest pull, when `regcomp` with `REG_EXTENDED` is compiling pattern with multiple adjacent '+', like "1*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++", the memory would be exhausted very quickly. Because in `duplicate_tree` it exponentially calls `create_token_tree` which malloc all the memory, looks like it's easy to cause serious DOS. Checked the regex specification that said "multiple adjacent duplication symbols ( '+', '*', '?', and intervals) produces undefined results.", and seems like other regex implementation have handled this, maybe glibc needs to handle it too? -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=17356 eggert at cs dot ucla.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|regex assertion violation |regex misbehavior with |with triple backreferences |triple backreferences --- Comment #5 from eggert at cs dot ucla.edu --- (In reply to Vincent Lefèvre from comment #4) Thanks, I've retitled it from "regex assertion violation with triple backreferences" to "regex misbehavior with triple backreferences". -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=17356 Vincent Lefèvre <vincent-srcware at vinc17 dot net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vincent-srcware at vinc17 dot net --- Comment #4 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> --- (In reply to eggert from comment #3) > Apparently I was incorrect when I wrote that this was a duplicate of > Bug#11053 as that other bug is fixed but this one is not. More precisely, the assertion violation was Bug#11053, which is fixed in glibc 2.35, but the test now fails: it gives no matches, while there should be a match, since the regexp matches the empty string. Test with grep: vinc17@gcc92:~$ echo 'a' | grep -E '(.{0,1})(.{0,1})\2\1' a vinc17@gcc92:~$ echo 'a' | grep -E '(.{0,1})(.{0,1})(.{0,1})\3\2\1' vinc17@gcc92:~$ (with only 2 backreferences, this is OK, but not with 3). The bug could be retitled. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=10844 Vincent Lefèvre <vincent-srcware at vinc17 dot net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vincent-srcware at vinc17 dot net -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=11053 --- Comment #25 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> --- (In reply to eggert from comment #24) > Sure, feel free to file it as a new bug. Bug 29560. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29560 Bug ID: 29560 Summary: Wrong result with backreferences (test for non-prime numbers) Product: glibc Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: regex Assignee: unassigned at sourceware dot org Reporter: vincent-srcware at vinc17 dot net CC: drepper.fsp at gmail dot com Target Milestone: --- Created attachment 14327 --> https://sourceware.org/bugzilla/attachment.cgi?id=14327&action=edit Testcase written in C zira:~> echo "1111111111111" | grep --color=always -E '^(11+)\1+$|^1?$' 1111111111111 with no colors, i.e. the matched portion is empty. This is incorrect: there shouldn't be any match, as there are 13 digits 1 and 13 is a prime number. This bug was initially reported in 2017 here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884075 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29613 It was also added in Bug 11053 comment 6, but Bug 11053 was actually a different bug. If the "|^1?$" part is replaced by "|^$" (matching an empty string), the issue still occurs, but if I remove it or replace it by a regexp that cannot match an empty string, the issue no longer occurs. I've attached a testcase written in C (almost the same as the one from Bug 11053 comment 6), using regcomp and regexec. This bug is still there in glibc 2.35 (Ubuntu 22.04.1 LTS / riscv64). -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=11053 --- Comment #24 from eggert at cs dot ucla.edu --- Sure, feel free to file it as a new bug. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=11053 --- Comment #23 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> --- What about attachment 10674 ("This test case silently returns the wrong answer"), with the pattern "^(11+)\\1+$|^1?$" and the string "1111111111111"? Should it be regarded as part of Bug#17356 or another bug? This case seems quite different from Bug#10844 and Bug#17356. Unless the intent is to group all the bugs about regexp involving backreferences giving a wrong answer[*] (in which case Bug#10844 and Bug#17356 should be regarded as duplicates to each other), I think that this should be a new bug. [*] as opposed to a crash like in this bug 11053. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=11053 --- Comment #22 from eggert at cs dot ucla.edu --- (In reply to Vincent Lefèvre from comment #21) > (In reply to eggert from comment #20) > > OK, so in that case how about if we update Bug#17356 by (1) saying it is no > > longer a duplicate of Bug#11053 (as we've fixed the latter but not the > > former), and (2) reopening Bug#17536? If I understand you correctly, that > > would match the symptoms you describe. > > Yes, I think that this is the best solution. OK, done. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=17356 eggert at cs dot ucla.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eggert at cs dot ucla.edu Resolution|DUPLICATE |--- Status|RESOLVED |REOPENED --- Comment #3 from eggert at cs dot ucla.edu --- Apparently I was incorrect when I wrote that this was a duplicate of Bug#11053 as that other bug is fixed but this one is not. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=11053 --- Comment #21 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> --- (In reply to eggert from comment #20) > OK, so in that case how about if we update Bug#17356 by (1) saying it is no > longer a duplicate of Bug#11053 (as we've fixed the latter but not the > former), and (2) reopening Bug#17536? If I understand you correctly, that > would match the symptoms you describe. Yes, I think that this is the best solution. -- You are receiving this mail because: You are on the CC list for the bug.