agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: malis@pgrust.com
Subject: BUG #19598: pg_waldump: -s/-e accept out-of-range WAL locations and silently use the low 32 bits
Date: Sun, 02 Aug 2026 17:49:43 +0000
Message-ID: <19598-aa67c8f4331611b4@postgresql.org> (raw)
The following bug has been logged on the website:
Bug reference: 19598
Logged by: Michael Malis
Email address: malis@pgrust.com
PostgreSQL version: 18.3
Operating system: Debian
Description:
Both LSN-accepting options parse with sscanf(optarg, "%X/%X", &xlogid,
&xrecoff) into two uint32s, with no length or range check. %X converts via
strtoul: a component that overflows uint32 is truncated to its low 32 bits,
and one that overflows uint64 saturates and then truncates. In both cases
sscanf still returns 2, so the != 2 "invalid WAL location" guard never fires
and the tool proceeds with a value the user did not ask for. PostgreSQL's
own canonical LSN parser rejects the same input.
Reproducer (runnable against stock PostgreSQL 18.3)
---------------------------------------------------
$ pg_waldump -s 123456789/0 000000010000000000000040
pg_waldump: error: start WAL location 23456789/0 is not inside file
"000000010000000000000040"
Note the echoed value: the 9-hex-digit input 123456789 was silently reduced
to 23456789. The saturating case:
$ pg_waldump -s FFFFFFFFFFFFFFFFFFFF/0 000000010000000000000040
pg_waldump: error: start WAL location FFFFFFFF/0 is not inside file
"..."
Control — a genuinely malformed value is rejected, so the guard works, it
just never sees these inputs:
$ pg_waldump -s ZZZ/0 000000010000000000000040
pg_waldump: error: invalid WAL location: "ZZZ/0"
Contrast with the server's own parser on the identical string:
SELECT '123456789/0'::pg_lsn;
ERROR: invalid input syntax for type pg_lsn: "123456789/0"
Expected vs. actual
-------------------
- Expected: pg_waldump: error: invalid WAL location: "123456789/0", as for
any other unparseable value.
- Actual: the value is accepted, silently mangled to 23456789/0, and used.
The error text the user eventually sees reports the mangled location,
which actively misleads: it reads as "the location you asked for isn't in
this file" when the location asked for was never used.
view thread (13+ messages) latest in thread
Message-ID: <19598-aa67c8f4331611b4@postgresql.org>
Permalink: ../19598-aa67c8f4331611b4@postgresql.org/
Also on: postgresql.org/message-id/19598-aa67c8f4331611b4@postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: noreply@postgresql.org, pgsql-bugs@lists.postgresql.org, malis@pgrust.com
Subject: Re: BUG #19598: pg_waldump: -s/-e accept out-of-range WAL locations and silently use the low 32 bits
In-Reply-To: <19598-aa67c8f4331611b4@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox