On Mon, Sep 21, 2026 at 10:00 PM Chao Li <li.evan.chao@gmail.com> wrote:
>
>
>
> > On Sep 22, 2026, at 03:51, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > Hi all,
> > (CCing Amit as the committer of this feature)
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > I've attached the patch to fix it. Feedback is very welcome.
> >
> > Regards,
> >
> > --
> > Masahiko Sawada
> > Amazon Web Services: https://aws.amazon.com
> > <v1-0001-Add-a-range-check-on-the-sequence-index-from-the-.patch>
>
> If the concern here is a malicious publisher, does it also make sense to replace Assert(!isnull) with a runtime check
andfail if seqidx is NULL?
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.
>
> Also there is a typo in the commit message:
> ```
> which bounds-checks only under assertinos, so it was possible that an
> ```
>
> assertinos -> assertions
Will fix it.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
