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: Harden tsquery code against overflows.
Date: Mon, 10 Aug 2026 13:41:21 +0000
Message-ID: <E1wtQFl-00000000y2v-2JB4@gemulon.postgresql.org> (raw)
Harden tsquery code against overflows.
The only overflow hazards I could find in tsquery construction
are in QTN2QT(), which builds a flat tsquery datum from the
QTNode tree representation used by tsquery_or, tsquery_rewrite,
and allied functions. There are two:
1. It seems theoretically possible for the outputs of cntsize() to
overflow an int, so I widened them to size_t. There's no hazard
certainly in tsquery_or and friends, but tsquery_rewrite could expand
the query tree by large multiples (by replacing many identical
subtrees with a large replacement tree), so in a 64-bit machine
with plenty of available memory it should be possible to build a
QTNode tree large enough to cause that. If these counters did
overflow then we'd under-allocate the output tsquery and have a heap
overwrite problem. size_t is sufficient, since it's counting the size
of a subset of an in-memory data structure. We also have to fix the
TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds
MaxAllocSize.
2. fillQT() neglects to check that the new "distance" value for a
QI_VAL item fits into the available 20-bit field. It's quite easy
to reach this, for example by tsquery_or'ing two near-megabyte-sized
tsquerys. However, the result is only a corrupt tsquery that does
not represent the expected query, so perhaps this doesn't rise to
the level of a security bug. Nonetheless it should be fixed.
Note: I followed the practice used in other tsquery code of checking
each distance value as it's assigned, which means that the last
operand string could extend past the MAXSTRPOS boundary. This is a
bit different from the pattern used for tsvectors, which insist that
the total data length not exceed MAXSTRPOS and thereby avoid making
per-item checks. Perhaps that should be harmonized sometime, but for
now it's okay for the two types to do this differently as long as
each one is self-consistent.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Backpatch-through: 14
Security: CVE-2026-14662
Branch
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/3b2238fbe9b9cc95f026fd4129804a72d0c22151
Author: Tom Lane <tgl@sss.pgh.pa.us>
Modified Files
--------------
src/backend/utils/adt/tsquery_util.c | 13 ++++++++++---
src/include/tsearch/ts_type.h | 3 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
view thread (6+ messages) latest in thread
Message-ID: <E1wtQFl-00000000y2v-2JB4@gemulon.postgresql.org>
Permalink: ../E1wtQFl-00000000y2v-2JB4@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1wtQFl-00000000y2v-2JB4@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: Harden tsquery code against overflows.
In-Reply-To: <E1wtQFl-00000000y2v-2JB4@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