Re: Strange GiST logic leading to uninitialized memory access in pg_trgm gist code

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Strange GiST logic leading to uninitialized memory access in pg_trgm gist code
Date: 2020-11-12 13:35:31
Message-ID: 87ft5eg2st.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Alexander" == Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:

>> Another issue I don't understand yet is that even though this code
>> is largely unchanged since 8.x, the original reporter could not
>> reproduce the crash on any version before 13.0.

Alexander> I think this is related to my commit 911e702077. It has
Alexander> changed the memory allocation for the signatures to support
Alexander> the signatures of variable length. So, it seems that despite
Alexander> the error existing since 8.x, it started causing segfaults
Alexander> only since 911e702077.

Aha. Prior to that change, cache[i].sign was an array rather than a
pointer, so it would not crash even when accessed without
initialization. What would happen instead is that an incorrect signature
would be used, which might lead to problems later in index lookups
(though I haven't tested that).

Alexander> I would rather propose to rip off special handling of the
Alexander> last item completely (see the attached patch).

Yeah. I'll go with that, once I finish testing it.

--
Andrew (irc:RhodiumToad)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-11-12 13:37:39 Re: Allow matching whole DN from a client certificate
Previous Message Andrew Dunstan 2020-11-12 13:19:39 Re: Proposition for autoname columns