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

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-04-07T08:57:27Z
Lists: pgsql-bugs
On Fri, Apr 7, 2023 at 4:21 AM PG Bug reporting form <noreply@postgresql.org>
wrote:

> The following script:
> CREATE EXTENSION intarray;
> CREATE TABLE test__int(a int[]);
> CREATE INDEX test_idx on test__int using gist (a gist__int_ops);
> INSERT INTO test__int SELECT array(SELECT x FROM generate_series(1, 1001)
> x)
> FROM generate_series(1, 10);
>
> causes a server crash:
> CREATE INDEX
> NOTICE:  input array is too big (199 maximum allowed, 1001 current), use
> gist__intbig_ops opclass instead
> NOTICE:  input array is too big (199 maximum allowed, 1001 current), use
> gist__intbig_ops opclass instead
> NOTICE:  input array is too big (199 maximum allowed, 1001 current), use
> gist__intbig_ops opclass instead


In g_int_compress,

 if (ARRNELEMS(r) >= 2 * num_ranges)
     elog(NOTICE, "input array is too big (%d maximum allowed, %d current),
use gist__intbig_ops opclass instead",
          2 * num_ranges - 1, ARRNELEMS(r));

Wondering why elog with NOTICE rather than Error here.

Thanks
Richard

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