Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David K <dkarapetyan(at)gmail(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)
Date: 2026-08-02 07:08:17
Message-ID: am7s4Qy325bbWiqx@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 31, 2026 at 11:15:08AM -0700, David K wrote:
> Thanks. That seems fine to me so is there anything else I need to do on my
> end?

- newSize += XLOG_BLCKSZ - (newSize % XLOG_BLCKSZ);
+ Assert(reclength <= INT32_MAX - BLCKSZ);
+
+ newSize = TYPEALIGN(XLOG_BLCKSZ, reclength);

Am I reading a typo here or the INT32_MAX is missing a 'PG_U'?
XLogRecordMaxSize cannot reach that, just wondering about a
consistency argument with the surrounding type declarations for these
length variables.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-08-02 07:20:01 Re: [PATCH] Doc: Mention OFF as an alias for EXPLAIN SERIALIZE NONE
Previous Message Peter Geoghegan 2026-08-02 07:03:01 Re: GiST multirange index scans can fail to return rows