Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\))
Subject: Re: Adding a range check on the sequence index from the publisher.
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAD21AoBvsyiybV40UxeB6LuVWhpp=TGUqUSbjRjHG4HC0H_7GA@mail.gmail.com>
Date: Wed, 23 Sep 2026 10:08:10 +0800
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Amit Kapila <amit.kapila16@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDFC20AF-1AC8-4ABC-BFEF-33A602BC5655@gmail.com>
References: 
 <CAD21AoBWDMuMmnevZaZ1xSOi75eUx8X7LbVQzmUZudk6F8Bdgg@mail.gmail.com>
 <A111188F-321D-4D4C-88F3-F1FA46AFCEA8@gmail.com>
 <CAD21AoBvsyiybV40UxeB6LuVWhpp=TGUqUSbjRjHG4HC0H_7GA@mail.gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/EDFC20AF-1AC8-4ABC-BFEF-33A602BC5655%40gmail.com>
Precedence: bulk


> On Sep 23, 2026, at 04:27, Masahiko Sawada <sawada.mshk@gmail.com> =
wrote:
>=20
> On Mon, Sep 21, 2026 at 10:00=E2=80=AFPM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>=20
>>=20
>>=20
>>> On Sep 22, 2026, at 03:51, Masahiko Sawada <sawada.mshk@gmail.com> =
wrote:
>>>=20
>>> Hi all,
>>> (CCing Amit as the committer of this feature)
>>>=20
>>> This was originally reported to pgsql-security by Anthropic OSS
>>> program but the security team considered it as a non-vuln bug since
>>> it's a v19-beta code, and I'm reporting here on behalf of them as =
it's
>>> permitted now.
>>>=20
>>> The reported problem is in sequencesync.c; the sequence
>>> synchronization worker uses an integer that came back from the
>>> publisher as a list subscript without checking it, and then writes
>>> through the resulting pointer.
>>>=20
>>> While it's not a problem in normal cases where the publisher is a
>>> normal PostgreSQL, it could lead to out-of-bounds writes when the
>>> publisher is a malicious server looking like a publisher.
>>>=20
>>> Other fields that we get through get_and_validate_seq_info() could
>>> also get the wrong value but they just show the wrong values rather
>>> than OOB writes. So I think we need a safeguard only for seqidx.
>>>=20
>>> I've attached the patch to fix it. Feedback is very welcome.
>>>=20
>>> Regards,
>>>=20
>>> --
>>> Masahiko Sawada
>>> Amazon Web Services: https://aws.amazon.com
>>> <v1-0001-Add-a-range-check-on-the-sequence-index-from-the-.patch>
>>=20
>> If the concern here is a malicious publisher, does it also make sense =
to replace Assert(!isnull) with a runtime check and fail if seqidx is =
NULL?
>=20
> I don't think we need it from a security perspective. Even if a
> malicious publisher returns NULL as seqidx, a garbage value is stored
> to *seqidx and will fail the new range check.
>=20

If a malicious publisher returns NULL for seqidx, the resulting *seqidx =
will likely be 0. Since 0 passes the range check, the first sequence =
could be silently selected, which might be incorrect.

On second thought, however, a malicious publisher could directly return =
a valid but incorrect seqidx, and we do not seem to have a way to =
protect against that. =46rom this perspective, checking isnull would not =
help much.

But from another perspective, an Assert is normally used for an internal =
invariant. Here, however, seqidx is received from external, so a runtime =
check seems more reasonable.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/