Horton

Re: BUG #17888: Incorrect memory access in gist__int_ops for an input array with many elements

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, Ankit Kumar Pandey <itsankitkp@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>, pgsql-bugs@lists.postgresql.org
Date: 2023-06-15T04:53:36Z
Lists: pgsql-bugs 
On Wed, Jun 14, 2023 at 01:21:40PM +0900, Michael Paquier wrote:
> Likely that's something we'd better backpatch, to avoid people playing
> with that too much in the back-branches.  Thoughts or objections?

Well, we could perhaps revisit the choice of 08ee64e to remove the
LEAF flag from the data stored.  However, seeing the lack of
complaints for the past 18 years with users storing large arrays under
gist__int_ops, spending more time on this is not really appealing,
either.  Or we would have heard about that because the decompression
immediately breaks for this case.

I have spent some time on that today, and applied what has been
suggested to restrict the usage of this operator when inserting data 
for a leaf page, so as the decompression does not get crazy when
retrieving the contents of the leaf pages.
--
Michael

Commits

  1. intarray: Prevent out-of-bound memory reads with gist__int_ops

  2. Remove usage of ArrayType->flags field, use pgsql's macros BITS_PER_BYTE instead