postgresql.git/src/pl, branch REL_19_STABLE

Defend against null "SV *" pointers in plperl modules.

2026-08-18T21:34:08Z

Tied hashes, and probably tied arrays, are capable of returning Perl value pointers that are actually NULL, not the usual pointer to an undef SV. We were not defending against that everywhere, leading to possible SIGSEGV. Fix the code to consistently treat a null pointer returned from hv_iternext or av_fetch like a !SvOK one. (Note that the large diff in SV_to_JsonbValue is actually quite trivial, but it required reindenting a chunk of existing code.) Claude Code found the instance in hstore_plperl, and I found the others by code auditing. Perhaps the other instances aren't actually reachable, but I see little reason to assume that. The known test cases for these errors require perl's Tie modules, which may not be present, so it doesn't seem worth the trouble to create regression test cases that would cover them. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14

Make plperl's handling of Perl arrays safer and more consistent.

2026-08-17T19:06:02Z

plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane Reviewed-by: Andrey Rachitskiy Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14

Use palloc_array() in pltcl and plperl to avoid overflow

2026-08-10T13:38:05Z

Some of these could overflow on 32-bit systems with the right input. Convert all cases where we called palloc() with multiplication to fix them. Not all of them were bugs, but it's better to be safe than sorry. Reported-by: Tulya Project, Team Dhiutsa, Bitecope Technologies Private Ltd Backpatch-through: 14 Security: CVE-2026-14677

Reject calls from SQL to functions that take or return type internal.

2026-08-10T13:38:04Z

Allowing that is a security hole, since there are many different functions with different ideas of what their "internal" argument or result is. We already had a defense against the easy case of "'foo'::internal", but that turns out to be insufficient. Lock down both function and operator syntax. Also disallow attempts to cast to or from type internal; those would mostly fail anyway, but we have created some holes with features such as CoerceViaIO. Reported-by: Amy Burnett (OpenAI Codex Security) Author: Tom Lane Reviewed-by: Robert Haas Backpatch-through: 14 Security: CVE-2026-14680

Protect some fixed-size arrays that have FUNC_MAX_ARGS elements.

2026-08-10T13:38:04Z

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 Author: Tom Lane Reviewed-by: Masahiko Sawada Backpatch-through: 14 Security: CVE-2026-14679

Harden PL/Perl code against "tied" Perl arrays and hashes.

2026-08-10T13:38:04Z

Tied arrays might report different sizes each time they are inspected. To avoid generating a corrupt result array, fix plperl_array_to_datum() to read av_len() of each input array only once. If the input does appear to get shorter, we'll fill nulls for the now-missing entries, which seems fine. Conversely, if it gets longer, we'll ignore the new entries. plperl_to_hstore() assumed that Perl's hv_iterinit() returns the number of entries in the given Perl hash. Usually that's true, but per the Perl docs, "the return value is currently only meaningful for hashes without tie magic". That could potentially end in a memory stomp. We don't depend on that result value anywhere else, so don't do so here either. Reported-by: Hcamael Author: Tom Lane Reviewed-by: Andrew Dunstan Backpatch-through: 14 Security: CVE-2026-14670

Translation updates

2026-08-10T10:10:27Z

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1cfa61615af29902242c24687492c8e49d94c1d0

Translation updates

2026-07-13T10:03:36Z

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 2ef2c86b2592e8a199edc86779bc44cfdb258971

Make PLy_elog() use pg_integer_constant_p().

2026-07-06T17:48:42Z

This macro is supposed to work like ereport(). But when 59c2f03d1 adjusted ereport() to be more MSVC-friendly, it missed updating this copy of the logic. Discussion: https://postgr.es/m/754534.1783264708@sss.pgh.pa.us Backpatch-through: 19

plpython: Fix NULL pointer dereferences for broken sequence and mapping objects

2026-06-29T02:38:39Z

PL/Python and its hstore and jsonb transforms build SQL values from Python containers by calling Python C API functions that can return NULL, and in several places the result was used without first checking it. On the sequence side, PySequence_GetItem() is used when converting a returned sequence into a SQL array or composite value, when reading the argument list passed to plpy.execute() or plpy.cursor(), and when reading the list of type names given to plpy.prepare(). On the mapping side, the hstore and jsonb transforms call PyMapping_Size() and PyMapping_Items() and then index the result with PyList_GetItem() and PyTuple_GetItem(). All of these return NULL (or -1), with a Python exception set, for a broken object: for example one whose __getitem__() or items() raises, or which reports a length that disagrees with what it actually yields. The unchecked result was then dereferenced, crashing the backend. Fix this by checking the result of each call and reporting a regular error if it failed, so that the underlying Python exception is surfaced instead of taking down the session. Author: Richard Guo Reviewed-by: Ayush Tiwari Discussion: https://postgr.es/m/CAMbWs49BKM9wP6m8bCXEpHwQKp7usvOGV6Jf=J7FYr_BCpxLqg@mail.gmail.com Backpatch-through: 14