Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wvdca-001Php-1Z for pgsql-hackers@arkaria.postgresql.org; Sun, 16 Aug 2026 16:22:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wvdcY-006XqN-19 for pgsql-hackers@arkaria.postgresql.org; Sun, 16 Aug 2026 16:22:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wvdcY-006XqC-0B for pgsql-hackers@lists.postgresql.org; Sun, 16 Aug 2026 16:22:03 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wvdcW-000000014gi-2Tai for pgsql-hackers@lists.postgresql.org; Sun, 16 Aug 2026 16:22:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 67GGLx4I455080 for ; Sun, 16 Aug 2026 12:21:59 -0400 From: Tom Lane To: pgsql-hackers@lists.postgresql.org Subject: Residual tsquery cleanups MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <454951.1786897233.0@sss.pgh.pa.us> Date: Sun, 16 Aug 2026 12:21:59 -0400 Message-ID: <455079.1786897319@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <454951.1786897233.1@sss.pgh.pa.us> The two attached, pretty trivial patches clean up some loose ends from the recent tsvector/tsquery security commits. I'm thinking of back-patching both, but perhaps there is an argument for not back-patching the first one? regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="v1-0001-Tighten-up-tsqueryrecv.patch"; charset="us-ascii" Content-ID: <454951.1786897233.2@sss.pgh.pa.us> Content-Description: v1-0001-Tighten-up-tsqueryrecv.patch Content-Transfer-Encoding: quoted-printable =46rom 5567ea2fb4ba82a5ebe4efaacef58715d95c9216 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 16 Aug 2026 12:08:22 -0400 Subject: [PATCH v1 1/2] Tighten up tsqueryrecv(). tsqueryrecv() accepted zero-length lexemes, which tsqueryin() doesn't. It also accepted phrase distance values larger than MAXENTRYPOS, which tsqueryin() doesn't. While neither of these omissions are very harmful in themselves, they do allow accepting tsquery values that will fail in a subsequent textual dump/reload. Commit 23d9ad771 performed similar tightening of tsvectorrecv(), but I left off these changes at the time because they didn't seem to have security implications. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane Backpatch-through: 14 --- src/backend/utils/adt/tsquery.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/backend/utils/adt/tsquery.c b/src/backend/utils/adt/tsque= ry.c index 3247d5db082..df26fc2a139 100644 --- a/src/backend/utils/adt/tsquery.c +++ b/src/backend/utils/adt/tsquery.c @@ -1272,6 +1272,9 @@ tsqueryrecv(PG_FUNCTION_ARGS) if (weight > 0xF) elog(ERROR, "invalid tsquery: invalid weight bitmap"); = + if (val_len =3D=3D 0) + elog(ERROR, "invalid tsquery: empty operand"); + if (val_len > MAXSTRLEN) elog(ERROR, "invalid tsquery: operand too long"); = @@ -1311,7 +1314,14 @@ tsqueryrecv(PG_FUNCTION_ARGS) = item->qoperator.oper =3D oper; if (oper =3D=3D OP_PHRASE) - item->qoperator.distance =3D (int16) pq_getmsgint(buf, sizeof(int16))= ; + { + unsigned int dist =3D pq_getmsgint(buf, sizeof(int16)); + + if (dist > MAXENTRYPOS) + elog(ERROR, "invalid tsquery: invalid phrase distance %d", + dist); + item->qoperator.distance =3D (int16) dist; + } } else elog(ERROR, "unrecognized tsquery node type: %d", item->type); -- = 2.52.0 ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name*0="v1-0002-Clean-up-documentation-about-text-search-datatype.p"; name*1="atch"; charset="us-ascii" Content-ID: <454951.1786897233.3@sss.pgh.pa.us> Content-Description: v1-0002-Clean-up-documentation-about-text-search-datatype.patch Content-Transfer-Encoding: quoted-printable =46rom 40adfc381b50c29014d05ee497c424a8ee7ac533 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 16 Aug 2026 12:15:26 -0400 Subject: [PATCH v1 2/2] Clean up documentation about text search datatype limits. textsearch.sgml neglected to mention that the MAXSTRPOS total-length limit applies to tsquery as well as tsvector. It also claims that there is a 32K limit on the total number of nodes in a tsquery, which is wrong. (I suspect that QueryOperator.left may once have been int16, which would give rise to such a limit. But it's uint32 now, so you'd hit the 1GB varlena limit well before overflowing that.) While at it, re-order the bullet points into an order that makes more sense, to me anyway. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane Backpatch-through: 14 --- doc/src/sgml/textsearch.sgml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml index d6d2ddeaacc..2f3a76bef1e 100644 --- a/doc/src/sgml/textsearch.sgml +++ b/doc/src/sgml/textsearch.sgml @@ -4046,24 +4046,24 @@ Parser: "pg_catalog.default" The length of each lexeme must be less than 2 kilobytes - The length of a tsvector (lexemes + positions) mu= st be - less than 1 megabyte + No more than 256 positions per lexeme Position values in tsvector must be greater than = 0 and no more than 16,383 - The match distance in a <N> - (FOLLOWED BY) tsquery operator cannot be more than - 16,384 + The length of a tsvector's data (lexemes + positi= ons) + must be less than 1 megabyte - No more than 256 positions per lexeme + The length of a tsquery's data (lexemes only) + must be less than 1 megabyte - The number of nodes (lexemes + operators) in a tsquery - must be less than 32,768 + The match distance in a <N> + (FOLLOWED BY) tsquery operator cannot be more than + 16,384 -- = 2.52.0 ------- =_aaaaaaaaaa0--