In the GNU C Library (aka glibc or libc6) through 2.29, check_dst_limits_calc_pos_1 in posix/regexec.c has Uncontrolled Recursion, as demonstrated by '(\227|)(\\1\\1|t1|\\\2537)+' in grep. Reference: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34141
Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1683153]
The regular expression compiler in glibc is only supposed to be exposed to trusted content, so this is not a security vulnerability: “resource exhaustion issues which can be triggered only with crafted patterns (either during compilation or execution) are not treated as security bugs” <https://sourceware.org/glibc/wiki/Security%20Exceptions>
Statement: The regular expression compiler in glibc is only supposed to be exposed to trusted content, therefore this flaw is not classified as a security vulnerability.
(In reply to Florian Weimer from comment #2) > The regular expression compiler in glibc is only supposed to be exposed to > trusted content, so this is not a security vulnerability: > > “resource exhaustion issues which can be triggered only with crafted > patterns (either during compilation or execution) are not treated as > security bugs” > > <https://sourceware.org/glibc/wiki/Security%20Exceptions> Hi Florian, I'd like to know a bit about how the compiler in glibc is only supposed to be exposed to trusted content, what does "trusted content" mean? This vulnerability is related to stack overflows due to recursion when processing patterns, according to the "Security Exceptions" document, this issue should be treated as a normal bug rather than a security issue. I have 2 questions, 1.- Why is this specific condition “Stack overflow due to recursion when processing patterns” not considered a security problem? 2.- How does the compiler in glibc (which part of the source code) evaluate the "trusted content" helping to avoid stack overflows due to recursion when processing patterns?