On Mon, Sep 21, 2026 at 10:00 PM Chao Li <[email protected]> wrote: > > > > > On Sep 22, 2026, at 03:51, Masahiko Sawada <[email protected]> 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 and fail 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
