Re: ARRNELEMS Out-of-bounds possible errors - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: ARRNELEMS Out-of-bounds possible errors
Date
Msg-id CAN-LCVNrkez+SSQOYtGPrVafmSZYm5gzYt_Gqhd2O6ebk7sZXQ@mail.gmail.com
Whole thread Raw
In response to ARRNELEMS Out-of-bounds possible errors  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: ARRNELEMS Out-of-bounds possible errors
List pgsql-hackers
Hi,

Actually, there would be much more sources affected, like
         nbytes += subbytes[outer_nelems];
         subnitems[outer_nelems] = ArrayGetNItems(this_ndims,
                                        ARR_DIMS(array));
         nitems += subnitems[outer_nelems];
         havenulls |= ARR_HASNULL(array);
         outer_nelems++;
      }

Maybe it is better for most calls like this to keep old behavior, by passing a flag
that says which behavior is expected by caller?

On Thu, Dec 22, 2022 at 6:36 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
Hi.

Per Coverity.

The commit ccff2d2, changed the behavior function ArrayGetNItems,
with the introduction of the function ArrayGetNItemsSafe.

Now ArrayGetNItems may return -1, according to the comment.
" instead of throwing an exception. -1 is returned after an error."

So the macro ARRNELEMS can fail entirely with -1 return,
resulting in codes failing to use without checking the function return.

Like (contrib/intarray/_int_gist.c):
{
int nel;

nel = ARRNELEMS(ent);
memcpy(ptr, ARRPTR(ent), nel * sizeof(int32));
}

Sources possibly affecteds:
contrib\cube\cube.c
contrib\intarray\_intbig_gist.c
contrib\intarray\_int_bool.c
contrib\intarray\_int_gin.c
contrib\intarray\_int_gist.c
contrib\intarray\_int_op.c
contrib\intarray\_int_tool.c:

Thoughts?

regards,
Ranier Vilela


--
Regards,
Nikita Malakhov
Postgres Professional 

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Call lazy_check_wraparound_failsafe earlier for parallel vacuum
Next
From: Peter Geoghegan
Date:
Subject: Re: New strategies for freezing, advancing relfrozenxid early