From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Make pg_regexec() robust against out-of-range search_start. |
Date: | 2021-09-11 19:21:02 |
Message-ID: | E1mP8Yg-00047q-Od@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/3adde7eb6633bea734c4513ebd96adca78b7737c
Modified Files
--------------
src/backend/regex/regexec.c | 2 ++
1 file changed, 2 insertions(+)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-09-13 00:04:11 | pgsql: Refactor the syslogger pipe protocol to use a bitmask for its op |
Previous Message | Tom Lane | 2021-09-10 17:18:55 | pgsql: Fix some anomalies with NO SCROLL cursors. |