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 tsvector code against overflows.
Date: Mon, 10 Aug 2026 13:41:23 +0000
Message-ID: <E1wtQFn-00000000y78-3BCC@gemulon.postgresql.org> (raw)
Harden tsvector code against overflows.
The core of this patch is to prevent array_to_tsvector() from
generating invalid tsvectors. It did not check for overly-long
lexemes (so that WordEntry.len fields could overflow), nor did it
check that the total "datalen" fits within MAXSTRPOS (so that
WordEntry.pos fields could overflow, and the number of entries
in the tsvector could be much more than the normal limit).
While the field overflows couldn't do anything much worse than
produce a corrupted tsvector value, a sufficiently large number
of tsvector entries could cause integer overflows in later
processing, such as tsvectorout.
Another important fix is to prevent tsvectorrecv() from accepting
invalid tsvectors. The main problem there is that it did not
reject empty-string lexemes. Hence, even though it did (mostly)
enforce the MAXSTRPOS limit, it could still produce a result
with an unreasonable number of tsvector entries, if they were
primarily empty strings.
Also, fix tsvectorout's calculation of its required output
buffer size: it was multiplying the string lengths by
pg_database_encoding_max_length() for no reason. That contributed
to the risk of integer overflow there. With valid tsvector input,
there's no risk, but there's still no reason to make the output
buffer several times bigger than needed.
I also tried to make a couple of related routines more robust,
and spent some effort on improving the comments in ts_type.h.
Also, standardize on a single spelling of the "string is too long
for tsvector" message, using %zu instead of an assortment of formats.
These changes aren't security per se but came out of inspecting the
code for problems.
Reported-by: Yuhang Wu <yuhang@depthfirst.com> and Zhenpeng Lin
Reported-by: Zheng Yu <zheng@depthfirst.com>
Reported-by: Hcamael <baiyjrh@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Backpatch-through: 14
Security: CVE-2026-14662
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e251350573e2ceb846b3b992f483d2d0de7a8a20
Author: Tom Lane <tgl@sss.pgh.pa.us>
Modified Files
--------------
src/backend/tsearch/to_tsany.c | 23 +++++++++++++++-----
src/backend/tsearch/ts_parse.c | 27 ++++++++++++++++++-----
src/backend/utils/adt/tsvector.c | 28 ++++++++++++++++++------
src/backend/utils/adt/tsvector_op.c | 40 +++++++++++++++++++++++++++++-----
src/include/tsearch/ts_type.h | 43 ++++++++++++++++++++++++++-----------
5 files changed, 126 insertions(+), 35 deletions(-)
view thread (6+ messages) latest in thread
Message-ID: <E1wtQFn-00000000y78-3BCC@gemulon.postgresql.org>
Permalink: ../E1wtQFn-00000000y78-3BCC@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1wtQFn-00000000y78-3BCC@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 tsvector code against overflows.
In-Reply-To: <E1wtQFn-00000000y78-3BCC@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