Re: BUG #19685: START_REPLICATION accepts an overflowing LSN component

Hi,

Thanks for the report, if I am right BUG #19598
<https://postgr.es/m/19598-aa67c8f4331611b4@postgresql.org> and this bug
are related. It was already discussed in that thread that the backend's own
sscanf()-based LSN parsers, like the one used here, could be handled
separately in a later patch.

If that's the right read and no one's already on it, I'd like to submit a
patch swapping the sscanf() there for pg_parse_lsn(), plus a regression
test covering the overflow cases from the original report (high-component
overflow, low-component overflow, and both). Happy to send it for review.

Regards,

On Sun, Sep 13, 2026 at 8:00 AM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 19685
> Logged by: Qifan Liu
> Email address: imchifan(at)163(dot)com
> PostgreSQL version: 18.6
> Operating system: Linux/amd64
> Description:
>
> A logical replication command accepts the LSN 100000000/1, whose high
> hexadecimal component exceeds 32 bits, and proceeds to slot or
> configuration
> validation. Inference: the replication scanner accepts an unbounded
> hexadecimal component and converts it to uint32 without enforcing the
> canonical range. The verified behavior is limited to START_REPLICATION;
> other source-identified LSN parsing paths were not exercised.
>
> Impact: The replication protocol silently accepts and transforms an invalid
> position instead of reporting malformed input. This creates inconsistent
> validation relative to canonical pg_lsn input and may cause replication to
> begin from a position different from the one supplied. Successful
> replication from the transformed position was not tested, and no crash,
> corruption, or security impact was observed.
>
>
> Steps to reproduce
> ------------------
> Prerequisites:
> - Run against a disposable PostgreSQL instance using a role allowed to
> issue
> replication protocol commands.
>
> ```sh
> psql -X -h /tmp 'dbname=postgres replication=database' -c
> 'START_REPLICATION
> SLOT nonexistent_slot LOGICAL 100000000/1 (proto_version '"'"'1'"'"',
> publication_names '"'"'nonexistent_publication'"'"')'
> ```
>
> Actual result
> -------------
> ```text
> stderr:
> ERROR: replication slot "nonexistent_slot" does not exist
> PostgreSQL server log:
> 2026-09-12 12:39:14.640 UTC [286] ERROR: replication slot
> "nonexistent_slot" does not exist
> 2026-09-12 12:39:14.640 UTC [286] STATEMENT: START_REPLICATION SLOT
> nonexistent_slot LOGICAL 100000000/1 (proto_version '1', publication_names
> 'nonexistent_publication')
> ```
>
> Expected result
> ---------------
> START_REPLICATION should reject the reproduced LSN 100000000/1 as out of
> range before performing replication-slot or wal_level validation.
>
> Additional information
> ----------------------
> The issue was reproduced on PostgreSQL 20devel, PostgreSQL 18.6, and
> PostgreSQL 17.11.
>
>
>
>
>