Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
Date
Msg-id CAH2-Wz=wjX9ADNR6V6eoTqC0J0FZo+VxmU2PPryMJKjZW=8wxg@mail.gmail.com
Whole thread Raw
In response to [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow  (skoposov@cmu.edu)
Responses Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow  (Sergey Koposov <skoposov@cmu.edu>)
Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow  (Sergey Koposov <skoposov@cmu.edu>)
List pgsql-bugs
On Thu, Jun 29, 2017 at 9:16 AM,  <skoposov@cmu.edu> wrote:
> From a quick look of the code it looks to me that the reason for the bug is
> the 32 bit int overflow in the j=2*i+1 calculation inside the
> tuplesort_heap_siftup leading to negative values of j.

It seems likely that the explanation is as simple as that. This
happens during run generation with replacement selection. All versions
are affected, but version 9.6+ is dramatically less likely to be
affected, because replacement selection was all but killed in Postgres
9.6.

This is an oversight in commit 263865a. The fix is to use a variable
that won't overflow in tuplesort_heap_siftup() -- this is probably a
one-liner, because when the variable overflows today, the correct
behavior would be for control to break out of the loop that declares
the overflowing variable "j", and, I don't see any similar problem in
other heap maintenance routines. It's a very isolated problem.

I could write a patch.

-- 
Peter Geoghegan


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Sergey Koposov
Date:
Subject: Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow
Next
From: Sergey Koposov
Date:
Subject: Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow