https://bugs.exim.org/show_bug.cgi?id=1991
--- Comment #2 from Kamil Frankowicz <fumfi....@gmail.com> --- (In reply to Philip Hazel from comment #1) > This is caused by a complicated regex with many nested parentheses. > Compiling such a pattern uses a lot of stack (especially when ASAN is > enabled; this increases stack usage). On my Linux box, compiling runs out of > stack with a 1Mb stack. With a larger stack, a different pattern runs out of > stack while matching (again, much more stack is needed for ASAN). There is > no problem with ASAN on my system if the stack is 4Mb or above. (And as I > keep grumbling, why do people run with such small stacks in these days of > gigabyte memories?) > > PCRE2 does not of itself guard against stack overflows. There are facilities > in PCRE2 for limiting the depth of parentheses in order to prevent stack > overrun when compiling. See the pcre2_set_parens_nest_limit() function. > There are facilities for limiting stack usage in pcre2_match(), but not at > present in pcre2_dfa_match(), which is where your matching stack overrun > happens (though not unless ASAN is in use). > > I will think about adding some limiting features for pcre2_dfa_match(). > Meanwhile, this specific issue is not a valid bug. I triggered this stack overflow on revision 760 (with ASAN) with much smaller payload (243 bytes versus 100 kilobytes). Please consider reopening this issue and adding limiting features in internal_dfa_match(). -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
