pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements.

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(-)

Browse pgsql-committers by date

  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.