agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. 6+ messages / 1 participants [nested] [flat]
* pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/60e7329b9b1dd1ca7bb2a39cf7d95e1d5b8b3a39 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/cache/funccache.c | 14 ++++++++++++++ src/backend/utils/fmgr/funcapi.c | 6 +++--- src/pl/tcl/pltcl.c | 22 +++++++++++++--------- 6 files changed, 109 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/42d9749b7ab56a7cbd751d136aea7abe1c0db887 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/cache/funccache.c | 14 ++++++++++++++ src/backend/utils/fmgr/funcapi.c | 6 +++--- src/pl/tcl/pltcl.c | 22 +++++++++++++--------- 6 files changed, 109 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2a03f21daf59c6d00a01d553b75bb74448a9593d 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/cache/funccache.c | 14 ++++++++++++++ src/backend/utils/fmgr/funcapi.c | 6 +++--- src/pl/tcl/pltcl.c | 22 +++++++++++++--------- 6 files changed, 109 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8a40f4b092987f735e712b789d8acbe3b3af8274 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/32e0d25d4c7d2f5a0d3ffd3edaa6eafdde2e223e 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. @ 2026-08-10 13:41 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-08-10 13:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-08-10 13:41 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-10 13:41 pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. Noah Misch <noah@leadboat.com> 2026-08-10 13:41 pgsql: Protect some fixed-size arrays that have FUNC_MAX_ARGS elements. Noah Misch <noah@leadboat.com>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox