Thread: [HACKERS] Fix freeing of dangling IndexScanDesc.xs_hitup in GiST

Hello, hackers!

The last query in the following script crashes Postgres:

create table t (id serial, amount int);
insert into t (amount) select random() * 1000 from generate_series(1, 100);
create extension btree_gist;
create index t_gist_idx on t using gist(id, amount);

select p.id, p.amount, s.nearest
from t as p left join lateral
(
   select p.id, array_agg(l.id) as nearest from (
     select id from t order by amount <-> p.amount limit 10
   ) l
) s using(id);

In gistrescan() IndexScanDesc.xs_hitup is not reset after MemoryContextReset() of
so->queueCxt in which xs_hitup was allocated, then getNextNearest() tries to pfree()
dangling xs_hitup, which results in the reuse of this pointer and the subsequent crash.

Attached patches fix this bug introduced in commit
d04c8ed9044eccebce043143a930617e3998c005 "Add support for index-only scans in GiST".
The bug is present in v9.5, v9.6, v10.0.

-- 
Nikita Glukhov
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company


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

Nikita Glukhov <n.gluhov@postgrespro.ru> writes:
> In gistrescan() IndexScanDesc.xs_hitup is not reset after MemoryContextReset() of
> so->queueCxt in which xs_hitup was allocated, then getNextNearest() tries to pfree()
> dangling xs_hitup, which results in the reuse of this pointer and the subsequent crash.

Right.  I already did something about this, about an hour ago --- a
bit differently from your patch, but same idea.
        regards, tom lane

On 04.05.2017 22:16, Tom Lane wrote:

> Nikita Glukhov <n.gluhov@postgrespro.ru> writes:
>> In gistrescan() IndexScanDesc.xs_hitup is not reset after MemoryContextReset() of
>> so->queueCxt in which xs_hitup was allocated, then getNextNearest() tries to pfree()
>> dangling xs_hitup, which results in the reuse of this pointer and the subsequent crash.
> Right.  I already did something about this, about an hour ago --- a
> bit differently from your patch, but same idea.
>
>             regards, tom lane

Sorry that I'm not monitoring pgsql-bugs.

It might be interesting that I found this bug back in July 2016 when I
was experimenting with my KNN-btree implementation, but I failed to report
it because I could reproduce it only manually by a calling in a loop
gistrescan() and gistgettuple().

-- 
Nikita Glukhov
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company