agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Noah Misch <noah@leadboat.com>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements.
Date: Mon, 10 Aug 2026 13:41:30 +0000
Message-ID: <E1wtQFu-00000000yJa-30ix@gemulon.postgresql.org> (raw)
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.mshk@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Backpatch-through: 14
Security: CVE-2026-14679
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/eb2fa2704b23ace6eadeb2958267b217c6533b96
Author: Tom Lane <tgl@sss.pgh.pa.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(-)
view thread (6+ messages)
Message-ID: <E1wtQFu-00000000yJa-30ix@gemulon.postgresql.org>
Permalink: ../E1wtQFu-00000000yJa-30ix@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1wtQFu-00000000yJa-30ix@gemulon.postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: noah@leadboat.com, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements.
In-Reply-To: <E1wtQFu-00000000yJa-30ix@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox