agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedBUG #19685: START_REPLICATION accepts an overflowing LSN component
3+ messages / 3 participants
[nested] [flat]
* BUG #19685: START_REPLICATION accepts an overflowing LSN component
@ 2026-09-12 15:33 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 3+ messages in thread
From: PG Bug reporting form @ 2026-09-12 15:33 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: imchifan@163.com
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.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19685: START_REPLICATION accepts an overflowing LSN component
@ 2026-09-13 03:25 Samriddha Kumar Tripathi <sumitkumartripathi0@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 3+ messages in thread
From: Samriddha Kumar Tripathi @ 2026-09-13 03:25 UTC (permalink / raw)
To: imchifan@163.com; pgsql-bugs@lists.postgresql.org
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@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.
>
>
>
>
>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19685: START_REPLICATION accepts an overflowing LSN component
@ 2026-09-13 04:48 Ayush Tiwari <ayushtiwari.slg01@gmail.com>
parent: Samriddha Kumar Tripathi <sumitkumartripathi0@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Ayush Tiwari @ 2026-09-13 04:48 UTC (permalink / raw)
To: Samriddha Kumar Tripathi <sumitkumartripathi0@gmail.com>; +Cc: imchifan@163.com; pgsql-bugs@lists.postgresql.org
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].
Patch added there should address it.
Regards,
Ayush
[1]
https://www.postgresql.org/message-id/CAJTYsWWN82LQzaVPX4D-P_yhooMf18OZ_6uO7jxdbrMaq1KexA%40mail.gma...
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-09-13 04:48 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-12 15:33 BUG #19685: START_REPLICATION accepts an overflowing LSN component PG Bug reporting form <noreply@postgresql.org>
2026-09-13 03:25 ` Samriddha Kumar Tripathi <sumitkumartripathi0@gmail.com>
2026-09-13 04:48 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox