[PATCH] Prevent overflow of datatotal in DecodeXLogRecord

From: Iliia Khaprov <i(dot)khaprov(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: [PATCH] Prevent overflow of datatotal in DecodeXLogRecord
Date: 2026-10-20 20:18:17
Message-ID: CAFO+O_pii=9oPTJ+4eJ+UV=zd9KF6SKcHMRbaYmghyfX1WHEOw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

pg_waldump segfaults on a 58-byte record with a valid CRC. The attached
script puts it in place of the first record of a fresh cluster's WAL.
Reproduced on 15 to master (e75fcc9867f).

DecodeXLogRecord sums the block data, image and main data lengths into
datatotal and checks it against the bytes left after the headers.
datatotal is a uint32 and main_data_len alone can be UINT32_MAX, so the
sum wraps to the remaining length and passes the check. The memcpy of
the main data then reads ~4 GB past the record.

18992dc9d98 capped xl_tot_len, but the lengths inside the record are
still summed in a uint32.

The patch makes datatotal a uint64, and the record is rejected with
"record with invalid length".

There is no test, because the record needs a valid CRC, which
039_end_of_wal.pl can't build. I can add one if wanted.

Best Regards,
Iliia

Attachment Content-Type Size
make-segment.sh text/x-sh 523 bytes
0001-Prevent-overflow-of-datatotal-in-DecodeXLogRecord.patch application/octet-stream 1.2 KB
record.bin application/macbinary 58 bytes

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-20 20:22:10 Re: [DEPARSE] Operators on ROW() constructors read back as row comparisons
Previous Message Iliia Khaprov 2026-10-20 19:46:11 Re: [PATCH] Remove useless ORDER BY from scalar subqueries