Re: BUG #19545: Integer truncation of `GinTuple.keylen` causes out-of-bounds read in parallel GIN index build

On 08/07/2026 09:27, Ewan Young wrote:
> Hi Yuelin,
>
> Thanks for the very precise report -- I reproduced it on master and your
> analysis is exactly right. _gin_build_tuple() builds the whole GinTuple
> (palloc size, key memcpy, TID-list offset) from the int keylen, but the
> stored GinTuple.keylen is uint16, so a key wider than 65535 bytes has its
> stored length truncated. On read-back GinTupleGetFirst() and
> _gin_parse_tuple_items() recompute the posting-list offset from the
> truncated value, and ginPostingListDecodeAllSegments() then walks the key
> bytes, aborting (or reading past the allocation on non-assert builds)
> exactly as you saw. It's parallel-only because only the parallel path
> serializes a GinTuple.
>
> I went with your fix A -- widening keylen to uint32 (attached). It's the
> minimal root-cause fix: the stored length now matches the length the rest
> of the function already uses.

Ugh, the datatypes used for keylen are all over the place. In GinTuple
struct it was 'uint16', in GinBuffer it's Size, and in the
_gin_build_tuple() function's local variable it's 'int'. Would be good
to make them consistent.

> I preferred it over an explicit ereport at
> UINT16_MAX, since 65535 isn't a meaningful GIN limit -- the entry-tree item
> limit is much smaller and is applied to the (compressed) tuple by
> GinFormTuple() -- so rejecting there would be an arbitrary cutoff.

Hmm, we don't compress the key data though, so a tuple with a key larger
than 65535 will inevitably fail in GinFormTuple(), right? I agree it
would be a little arbitrary to cut off at 65535, but then again, it
seems a little silly to continue when we know it's just going to fail
later on. I think it would make sense to check if keylen >
GinMaxItemSize. It might still fail later in GinFormTuple(), because the
index tuple headers take some space, but still.

- Heikki