Re: Fw: Re: heap_force_common in contrib/pg_surgery/heap_surgery.c has an off by one stack buffer overflow - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Fw: Re: heap_force_common in contrib/pg_surgery/heap_surgery.c has an off by one stack buffer overflow
Date
Msg-id aiIHe-G6Kg1fXbeb@paquier.xyz
Whole thread
List pgsql-bugs
On Thu, Jun 04, 2026 at 02:42:23PM +0530, Ashutosh Sharma wrote:
> These are admittedly small risks, but they are real ones. Keeping the
> array 1-based eliminates that entire class of potential confusion and
> makes the code easier to maintain going forward. I'd lean toward
> Surya's approach for that reason.

That depends on the code path involved:
- pruneheap.c has "processed" and "htsv", that use a +1 index to avoid
the substract, where we also worry about performance.
- heapam_handler.c has in_index, that uses a -1 index.

At the end, the first pattern is an outlier, we don't need to worry
about performance in pg_surgery, and we're talking about three lines
of code in pg_surgery to change (two for include_this_tid, one for the
assertion).  With all that in mind, I'd just do a -1 conversion and
call it a day.  :)
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #19509: Typo in 19 beta release notes (debug_print_parse)
Next
From: Amjad Shahzad
Date:
Subject: Re: BUG #19510: refint.c: SQL injection via unquoted identifier arguments in check_primary_key and check_foreign_key