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

Hi,

On Sun, 13 Sept 2026 at 08:55, Samriddha Kumar Tripathi <
sumitkumartripathi0(at)gmail(dot)com> wrote:
>
> Hi,
>
> Thanks for the report, if I am right BUG #19598 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.

This looks like a duplicate of [1].

Patch added there should address it.

Regards,
Ayush

[1]
https://www.postgresql.org/message-id/CAJTYsWWN82LQzaVPX4D-P_yhooMf18OZ_6uO7jxdbrMaq1KexA%40mail.gmail.com