mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-23 06:10:41 +02:00
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
This commit is contained in:
parent
9ea8d3d24a
commit
3be381a900
@ -196,6 +196,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);
|
||||||
|
Loading…
Reference in New Issue
Block a user