Make pg_regexec() robust against out-of-range search_start.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 11 Sep 2021 19:19:31 +0000 (15:19 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 11 Sep 2021 19:20:04 +0000 (15:20 -0400)
commitdaac97eb0b9f680916561ae636ce554fbeec8bd5
treeb34bf38b3d2871f0f2f94bcd47a1f58a84e95bfd
parentca1dd6234049bd5f9c06c45b0bffc867120eaac3
Make pg_regexec() robust against out-of-range search_start.

If search_start is greater than the length of the string, we should just
return REG_NOMATCH immediately.  (Note that the equality case should
*not* be rejected, since the pattern might be able to match zero
characters.)  This guards various internal assumptions that the min of a
range of string positions is not more than the max.  Violation of those
assumptions could allow an attempt to fetch string[search_start-1],
possibly causing a crash.

Jaime Casanova pointed out that this situation is reachable with the
new regexp_xxx functions that accept a user-specified start position.
I don't believe it's reachable via any in-core call site in v14 and
below.  However, extensions could possibly call pg_regexec with an
out-of-range search_start, so let's back-patch the fix anyway.

Discussion: https://postgr.es/m/20210911180357.GA6870@ahch-to
src/backend/regex/regexec.c