Fix out-of-bounds array indexing in JsonValueList
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253982psql -h localhost -U postgresBuilt from patchset v5 (message #5), October 22, 2026 at 04:48 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253982_5 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253982_5 && git checkout t253982_5Patchset v5 (message #5) is on t253982_5
I know the $subject can be scary, but I want to preface that we have NO
memory overruns here.
When compiling Postgres with -fsanitize=bounds, I get the following
errors in the log:
jsonpath_exec.c:3832:3: runtime error: index 3 out of bounds for type 'JsonbValue[2]'
jsonpath_exec.c:3918:10: runtime error: index 3 out of bounds for type 'JsonbValue[2]'
The lines corrspond to accesses in JsonValueListAppend() and
JsonValueListNext(). A query like the following is enough to trigger the
errors:
SELECT jsonb_path_query('[1,2,3,4,5,6]', '$[*]');
This behavior was introduced in
5a2043bf713113b0f6e9dbf2046499a5ca67883c[0]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5a2043bf713113b0f6e9dbf2046499a5ca67883c. It made JsonValueList
a chunked list whose first chunk lives on the caller's stack. All chunks
shared one struct type, whose trailing array was declared as
items[BASE_JVL_ITEMS]. Extra chunks were allocated with room for more
entries and code indexed past the declared bound of 2.
C11 6.5.6p8 makes pointer arithmetic that does more than one element
past the end of an array undefined behavior, and Annex J.2 confirms this
holds "even if an object is apparently accessible with the given
subscript".
We can fix this by separating JsonValueList into two structs:
JsonValueList and JsonValueListChunk. JsonValueList holds the first
BASE_JVL_ITEMS, and it points to any subsequent JsonValueListChunks,
which hold additional items.
I think this is good motivation (for me) for standing up a buildfarm
animal to catch these sorts of issues. CCing Peter since he has started
committing some of my related counted_by work.
C11 Standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
On 29.09.26 06:04, Tristan Partin wrote:
When compiling Postgres with -fsanitize=bounds, I get the following
errors in the log:jsonpath_exec.c:3832:3: runtime error: index 3 out of bounds for type 'JsonbValue[2]'
jsonpath_exec.c:3918:10: runtime error: index 3 out of bounds for type 'JsonbValue[2]'
I've run into this problem as well, but only when compiling with
-fstrict-flex-arrays=1. Is that what you are using?
I would like to get this fixed, because this site appears to be the only
problem of this kind. I will check your proposal.
On 29.09.26 07:50, Peter Eisentraut wrote:
On 29.09.26 06:04, Tristan Partin wrote:
When compiling Postgres with -fsanitize=bounds, I get the following
errors in the log:jsonpath_exec.c:3832:3: runtime error: index 3 out of bounds for
type 'JsonbValue[2]'
jsonpath_exec.c:3918:10: runtime error: index 3 out of bounds for
type 'JsonbValue[2]'I've run into this problem as well, but only when compiling with -
fstrict-flex-arrays=1. Is that what you are using?I would like to get this fixed, because this site appears to be the only
problem of this kind. I will check your proposal.
I played around with this a bit more and came up with the attached
solution, which is much simpler but requires that we don't go higher
than -fstrict-flex-arrays=1 -- which we can't anyway for other reasons
shown in the patch.
On Oct 5, 2026, at 7:51 AM, Peter Eisentraut <peter@eisentraut.org> wrote:
On 29.09.26 07:50, Peter Eisentraut wrote:
On 29.09.26 06:04, Tristan Partin wrote:
When compiling Postgres with -fsanitize=bounds, I get the following
errors in the log:jsonpath_exec.c:3832:3: runtime error: index 3 out of bounds for
type 'JsonbValue[2]'
jsonpath_exec.c:3918:10: runtime error: index 3 out of bounds for
type 'JsonbValue[2]'I've run into this problem as well, but only when compiling with -
fstrict-flex-arrays=1. Is that what you are using?I would like to get this fixed, because this site appears to be the only
problem of this kind. I will check your proposal.I played around with this a bit more and came up with the attached
solution, which is much simpler but requires that we don't go higher
than -fstrict-flex-arrays=1 -- which we can't anyway for other reasons
shown in the patch.
<v1.5-0001-Add-compiler-option-fstrict-flex-arrays-1.patch>
Thanks Peter.
I took a look. It seems to make the right trade-offs for where we are
and add value where we can. I like the use of the union, too bad that
struct isn't at the end so we could use FLEXIBLE_ARRAY_MEMBER.
+1
-greg
On Mon Oct 5, 2026 at 2:37 PM UTC, Greg Burd wrote:
On Oct 5, 2026, at 7:51 AM, Peter Eisentraut <peter@eisentraut.org> wrote:
On 29.09.26 07:50, Peter Eisentraut wrote:
On 29.09.26 06:04, Tristan Partin wrote:
When compiling Postgres with -fsanitize=bounds, I get the following
errors in the log:jsonpath_exec.c:3832:3: runtime error: index 3 out of bounds for
type 'JsonbValue[2]'
jsonpath_exec.c:3918:10: runtime error: index 3 out of bounds for
type 'JsonbValue[2]'I've run into this problem as well, but only when compiling with -
fstrict-flex-arrays=1. Is that what you are using?I would like to get this fixed, because this site appears to be the only
problem of this kind. I will check your proposal.I played around with this a bit more and came up with the attached
solution, which is much simpler but requires that we don't go higher
than -fstrict-flex-arrays=1 -- which we can't anyway for other reasons
shown in the patch.
<v1.5-0001-Add-compiler-option-fstrict-flex-arrays-1.patch>Thanks Peter.
I took a look. It seems to make the right trade-offs for where we are
and add value where we can. I like the use of the union, too bad that
struct isn't at the end so we could use FLEXIBLE_ARRAY_MEMBER.
I concur with Greg that it looks fine. Attached is another potential
solution if we didn't want treewide -fstrict-flex-arrays=1. I saw that
GCC supports a strict_flex_array attribute, which Clang does not
currently support. Your solution is probably better for that reason, but
I figured that I would post this anyway.
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)