Re: [pcre-dev] pcre_exec() with out-of-bounds offset

On Mon, 8 Nov 2010, Ralf Junker wrote:

> With the list above I wanted to draw your attention to the fact that
> apparently only n was initialized, but n+1 was not (my list is offset by
> 1). In other words: The first element of the pair is initialized while
> the second is not.

Ah. I did not realize that your list was offset by one.

> As I read the docs, ovector should always be set in pairs only (n plus
> n+1) or be uninitialized in pairs. Applications might use this to
> simplify their test for unmatched subpatterns by testing either n or n+1
> instead of both values.

I have had a look through the code, and I cannot find anywhere that n is
set and n+1 is not. However, there are places where values are saved and
restored, so it does get complicated.

At the start of each matching cycle, pcre_exec() is supposed to set all
relevant offset values to -1, including the first two. It is therefore
odd that your offsets[2] (which I think of as offsets[1]) is
-2147483640.

But ... we know crazy things were going on owing to the lack of a check
on the value of start_offset, so maybe that was the cause. If you can
make this happen again, with the patched code, please let me know what
the pattern and subject were!

Philip

--
Philip Hazel