postgres.git / summary / log / commit / refs

commit    b33283cbd336adbf982c21aac1399130c8ffaaa9
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Sat Sep 11 19:19:31 2021 +0000

    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


 src/backend/regex/regexec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/backend/regex/regexec.c b/src/backend/regex/regexec.c
index f19fb988199..e72aa8ccfb1 100644
--- a/src/backend/regex/regexec.c
+++ b/src/backend/regex/regexec.c
@@ -200,6 +200,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);


[parent: d844cd75a676]