Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
Subject: Re: Potential buffer overrun in spell.c's CheckAffix()
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <641711.1776792744@sss.pgh.pa.us>
Date: Wed, 22 Apr 2026 16:57:26 +0500
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6506DC9-7E95-4FA3-A9E3-37392E92463D@yandex-team.ru>
References: <641711.1776792744@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/F6506DC9-7E95-4FA3-A9E3-37392E92463D%40yandex-team.ru>
Precedence: bulk


> On 21 Apr 2026, at 22:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> if (Affix->type =3D=3D FF_SUFFIX)
> {
> + /* protect against buffer overrun */
> + if (len < Affix->replen || len >=3D 2 * MAXNORMLEN ||
> + len - Affix->replen + findlen >=3D 2 * MAXNORMLEN)
> + return NULL;
> +
> strcpy(newword, word);
> strcpy(newword + len - Affix->replen, Affix->find);
> if (baselen) /* store length of non-changed part of word */
> @@ -2112,11 +2139,16 @@ CheckAffix(const char *word, size_t len, AFFIX =
*Affix, int flagflags, char *neww
> }
> else
> {
> + /* protect against buffer overrun */
> + if (len < Affix->replen ||
> + findlen + len - Affix->replen >=3D 2 * MAXNORMLEN)
> + return NULL;

Is there a reason for an asymmetric check "len >=3D 2 * MAXNORMLEN =
||=E2=80=9D?
Both cases seem symmetrical and we could move it out of =E2=80=9Cif".


> On 22 Apr 2026, at 03:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> I chose to do this by silently truncating the input before it can
> overrun the buffer, using logic comparable to the existing logic in
> get_nextfield().  Certainly there's at least as good an argument for
> raising an error, but for now let's follow the existing precedent.

Is there a reason not to emit WARNING? The data is obviously =
suspicious=E2=80=A6
Perhaps, there=E2=80=99s a reason, so maybe just document it then.

Both patches look good to me, AFAICT.


Best regards, Andrey Borodin.=