Feedback-ID: idd01497b:Fastmail
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 05 Jun 2026 15:57:53 +0000
Message-Id: <DJ18MRKAVFG9.1X19THWF6N43F@partin.io>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: Re: dict_synonym.c: fix truncation of multibyte sequence
To: "Jeff Davis" <pgsql@j-davis.com>
From: "Tristan Partin" <tristan@partin.io>
References: <1101e1a3afbbabb503317069c40374b82e6f4cac.camel@j-davis.com>
In-Reply-To: <1101e1a3afbbabb503317069c40374b82e6f4cac.camel@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DJ18MRKAVFG9.1X19THWF6N43F%40partin.io>
Precedence: bulk

On Thu Jun 4, 2026 at 10:07 PM UTC, Jeff Davis wrote:
>
> If case_sensitive is false and str_tolower() changes the byte length of
> the string, then outlen will be incorrect.
>
> Fortunately, pnstrdup() also stops at a NUL terminator, so it will
> never overrun; but if outlen is calculated to be too small, then it
> could cause truncation. In any case, the input comes from a trusted
> source (dictionary configuration), so it's not very serious.
>
> The correct value of outlen is strlen(d->syn[cur].out). But it's only
> ever used in one place, which is a call to pnstrdup(). Given that the
> string is NUL-terminated anyway, it's easier to fix it by just changing
> that to a pstrdup(). Patch attached, backpatch all the way.

The fix looks and sounds good. Do we have any way to test this, so it=20
doesn't regress in the future? Do we need to export a module to test=20
through SQL?

--=20
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)