aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/basics.source
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-09-11 15:19:31 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-09-11 15:19:31 -0400
commite757080e041214cf6983e3e77ef01e83f1371d72 (patch)
tree05788a733507fcfdf23a84d69d8121a22660b1d1 /src/tutorial/basics.source
parentc1b7a6c2731241cf5af4c08de54a64fc8999d727 (diff)
downloadpostgresql-e757080e041214cf6983e3e77ef01e83f1371d72.tar.gz
postgresql-e757080e041214cf6983e3e77ef01e83f1371d72.zip
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
Diffstat (limited to 'src/tutorial/basics.source')
0 files changed, 0 insertions, 0 deletions