https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #44 from Zoltan Herczeg <hzmester@???> ---
> $62 = {flags = 115, study_data = 0x555555d33610, match_limit = 1000000,
> callout_data = 0x0,
> tables = 0x21e <error: Cannot access memory at address 0x21e>,
> match_limit_recursion = 100000, mark = 0x7fffffff9288,
> executable_jit = 0x555555d33650}
The 115 is 0x73, so 0x20 is indeed set in flags. The 0x7fffffff9288 for mark is
a typical stack address. I thought PCRE_EXTRA_MARK is connected to 's' but it
is probably not. Perhaps PCRE_EXTRA_MARK is always set.
You are probably right about the issue you found. In the past study data was
never passed, so setting PCRE_EXTRA_MARK did not cause any problem. But now it
is, a random memory address is overwritten with NULL.
I think they really need to change the character advancing to something more
efficient like:
if (g_notempty != 0 && start_offset < subject_len) {
offsets[0] = start_offset;
offsets[1] = start_offset + 1;
if (pce->compile_options & PCRE_UTF8) {
while (offsets[1] < subject + subject_len
&& (subject[offsets[1]] & 0xc0) == 0x80) {
offsets[1]++;
}
}
}
Because using pcre to advancing just one UTF character ahead is the most
inefficient way I can imagine.
Regardless, the PCRE_EXTRA_MARK flag may cause other side effects (memory
overwrites if the mark pointer is invalid) so I would check thoroughly in the
engine.
--
You are receiving this mail because:
You are on the CC list for the bug.
