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:49 -0400 |
| commit | 7e420072ea4a9f873d3378c8b35f2d939d925022 (patch) | |
| tree | 290cc37695095d450c476a670cc11acae3395f7f /src/backend/regex/regexec.c | |
| parent | fa5d0415f10fac3c2aa4c301840fde1780b91b79 (diff) | |
| download | postgresql-7e420072ea4a9f873d3378c8b35f2d939d925022.tar.gz postgresql-7e420072ea4a9f873d3378c8b35f2d939d925022.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/backend/regex/regexec.c')
| -rw-r--r-- | src/backend/regex/regexec.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/backend/regex/regexec.c b/src/backend/regex/regexec.c index 34381ff8d9a..460c987a607 100644 --- a/src/backend/regex/regexec.c +++ b/src/backend/regex/regexec.c @@ -196,6 +196,8 @@ pg_regexec(regex_t *re, return REG_INVARG; if (re->re_csize != sizeof(chr)) return REG_MIXED; + if (search_start > len) + return REG_NOMATCH; /* Initialize locale-dependent support */ pg_set_regex_collation(re->re_collation); |