Thread: pgsql: Fix array overrun in regex code.

pgsql: Fix array overrun in regex code.

From
Tom Lane
Date:
Fix array overrun in regex code.

zaptreesubs() was coded to unconditionally reset a capture subre's
corresponding pmatch[] entry.  However, in regexes without backrefs, that
array is caller-supplied and might not have as many entries as the regex
has capturing parens.  So check the array length and do nothing if there
is no corresponding entry, much as subset() does.  Failure to check this
resulted in a stack clobber in the case reported by Marko Kreen.

This bug appears to have been latent in the regex library from the
beginning.  It was not exposed because find() called dissect() not
cdissect(), and the dissect() code path didn't ever call zaptreesubs()
(formerly zapmem()).  When I unified dissect() and cdissect() in commit
4dd78bf37aa29d04b3f358b08c4a2fa43cf828e7, the problem was exposed.

Now that I've seen this, I'm rather suspicious that we might need to
back-patch it; but will refrain for now, for lack of evidence that
the case can be hit in the previous coding.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/2a4c46e0baf2d51117cd4468b28705d01ffcbff9

Modified Files
--------------
src/backend/regex/regexec.c         |   13 +++++++++----
src/test/regress/expected/regex.out |   19 +++++++++++++++++++
src/test/regress/sql/regex.sql      |    5 +++++
3 files changed, 33 insertions(+), 4 deletions(-)