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 23:21:19
Message-ID: am_Q7owT_hz4GTpr@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 02, 2026 at 04:08:17PM +0900, Michael Paquier wrote:
> - 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.

Another thing to note: this basically breaks the recovery test
039_end_of_wal.pl. Could you look at that please?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-02 23:35:35 Re: Fix a host of strto*() bugs
Previous Message Alexander Korotkov 2026-08-02 20:43:39 Re: [PATCH] Fix replica identity mismatch for partitioned tables with publish_via_partition_root