| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. |
| Date: | 2026-08-10 13:41:30 |
| Message-ID: | E1wtQFu-00000000yJa-30ix@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Protect some fixed-size arrays that have FUNC_MAX_ARGS elements.
The maximum number of arguments allowed for an aggregate function
is FUNC_MAX_ARGS-1 (since the underlying transfn and/or finalfn
will be called with one more argument). parse_func.c failed to
enforce this, allowing construction of calls that would try to
pass FUNC_MAX_ARGS+1 to the underlying functions, resulting in
a memory stomp in the executor. Add correct checking there.
Since it's possible that a bad call has been stored in a view or
SQL function, also add checks in various aggregate-related and
window-function-related code that there are not more than
FUNC_MAX_ARGS arguments. These will also protect us against the
possibility that we're trying to run a stored view that was made
by a server executable with different FUNC_MAX_ARGS. (Arguably,
that scenario does not qualify as a security problem. But let's
just tighten up all of this while we're here, rather than split
hairs over whether an overrun is reachable.)
Likewise check in compute_function_hashkey. Here the hazard is
directly from a pg_proc row, but the scenario is the same.
PL/Tcl has a similar issue with a fixed-size string buffer.
Let's just replace that buffer with a Tcl_DString, removing the
whole issue and making the code look more like what's around it.
There are a lot of other FUNC_MAX_ARGS-sized arrays, but the rest
have nearby guards already, some with comments explicitly pointing
out the hazard of FUNC_MAX_ARGS changing.
I also used palloc_array() in a few related places in funcapi.c.
Those aren't live hazards AFAICS, but nearby code has been
palloc_array-ified already, so it seemed inconsistent to not use
it here.
Reported-by: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Reviewed-by: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Backpatch-through: 14
Security: CVE-2026-14679
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/eb2fa2704b23ace6eadeb2958267b217c6533b96
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Modified Files
--------------
src/backend/executor/nodeWindowAgg.c | 33 +++++++++++++++++++++++++++++++++
src/backend/parser/parse_agg.c | 18 +++++++++++++++++-
src/backend/parser/parse_func.c | 29 +++++++++++++++++++++++++++++
src/backend/utils/fmgr/funcapi.c | 6 +++---
src/pl/plpgsql/src/pl_comp.c | 14 ++++++++++++++
src/pl/tcl/pltcl.c | 22 +++++++++++++---------
6 files changed, 109 insertions(+), 13 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2026-08-10 13:41:31 | pgsql: Invalidate plan cache after role changes. |
| Previous Message | Noah Misch | 2026-08-10 13:41:29 | pgsql: Avoid overflow in Levenshtein distance calculations. |