mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-21 08:29:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

Make pg_regexec() robust against out-of-range search_start.

Browse Source 
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
This commit is contained in:
Tom Lane 2021-09-11 15:19:31 -04:00
parent c1b7a6c273
commit e757080e04
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/backend/regex/regexec.c
View File

@ -200,6 +200,8 @@ pg_regexec(regex_t *re,
return REG_INVARG; return REG_INVARG;
if (re->re_csize != sizeof(chr)) if (re->re_csize != sizeof(chr))
return REG_MIXED; return REG_MIXED;
if (search_start > len)
return REG_NOMATCH;
/* Initialize locale-dependent support */ /* Initialize locale-dependent support */
pg_set_regex_collation(re->re_collation); pg_set_regex_collation(re->re_collation);