]> granicus.if.org Git - postgresql/commit
Fix array overrun in regex code.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 24 May 2012 17:56:16 +0000 (13:56 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 24 May 2012 17:56:16 +0000 (13:56 -0400)
commit2a4c46e0baf2d51117cd4468b28705d01ffcbff9
treecf989d8d3b6a7ba0f6572fe35c9bee5c74cf7b20
parentace397e9d24eddc56e7dffa921f506117b602d78
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.
src/backend/regex/regexec.c
src/test/regress/expected/regex.out
src/test/regress/sql/regex.sql