BUG #19685: START_REPLICATION accepts an overflowing LSN component

Hi,

Thanks for the report, if I am right BUG #19598
</messages/by-id/19598-aa67c8f4331611b4@postgresql.org&gt; 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@postgresql.org> wrote:

Hi,

On Sun, 13 Sept 2026 at 08:55, Samriddha Kumar Tripathi <
sumitkumartripathi0@gmail.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@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 19685
Logged by: Qifan Liu
Email address: imchifan@163.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]/messages/by-id/CAJTYsWWN82LQzaVPX4D-P_yhooMf18OZ_6uO7jxdbrMaq1KexA@mail.gmail.com.

Patch added there should address it.

Regards,
Ayush

[1]: /messages/by-id/CAJTYsWWN82LQzaVPX4D-P_yhooMf18OZ_6uO7jxdbrMaq1KexA@mail.gmail.com
/messages/by-id/CAJTYsWWN82LQzaVPX4D-P_yhooMf18OZ_6uO7jxdbrMaq1KexA@mail.gmail.com