| 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 |
| 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 |