https://bugs.exim.org/show_bug.cgi?id=1991
--- Comment #2 from Kamil Frankowicz <fumfi.255@???> ---
(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.
