Re: Fw: Re: heap_force_common in contrib/pg_surgery/heap_surgery.c has an off by one stack buffer overflow

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: "violin0613(at)tju(dot)edu(dot)cn" <violin0613(at)tju(dot)edu(dot)cn>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Fw: Re: heap_force_common in contrib/pg_surgery/heap_surgery.c has an off by one stack buffer overflow
Date: 2026-06-04 07:31:20
Message-ID: aiEpyJteDv3q-EMi@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jun 03, 2026 at 03:31:27PM -0700, surya poondla wrote:
> Thank you for reporting the issue, I am able to reproduce it on master.
> The include_this_tid[] array is sized MaxHeapTuplesPerPage but indexed
> using 1-based OffsetNumber,
> so the largest legal offset (MaxHeapTuplesPerPage itself) lands one slot
> past the end.

- bool include_this_tid[MaxHeapTuplesPerPage];
+ /* Sized +1 because OffsetNumbers are 1-based and can reach MaxHeapTuplesPerPage. */
+ bool include_this_tid[MaxHeapTuplesPerPage + 1];

The offset number begins at 1. Hence, instead of making this array
larger by one, you could keep it at the same size and adjust the array
index to use (offno - 1) instead.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-06-04 07:37:13 BUG #19507: Auto-named partition table constraint conflicts
Previous Message Antonin Houska 2026-06-04 06:31:41 Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API