diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-09-11 15:19:31 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-09-11 15:19:58 -0400 |
commit | 3be381a900df75de6a085cc3a465d85ec8bf39cd (patch) | |
tree | 0dbdeb5ab4a1fa6d7b7cec10d84932f99a60ace2 /src/include/postgres.h | |
parent | 9ea8d3d24a9fb2bbe99cb17f6ee08747f662aabd (diff) | |
download | postgresql-3be381a900df75de6a085cc3a465d85ec8bf39cd.tar.gz postgresql-3be381a900df75de6a085cc3a465d85ec8bf39cd.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/include/postgres.h')
0 files changed, 0 insertions, 0 deletions