Re: Possible dereference after null check (src/backend/executor/ExecUtils.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible dereference after null check (src/backend/executor/ExecUtils.c)
Date: 2021-02-12 16:11:58
Message-ID: CAEudQAqchb52Dc0Sqh5r6kzzAA=27r3KUO1F8B2_FeJhxB08Ow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em sex., 12 de fev. de 2021 às 03:28, Kyotaro Horiguchi <
horikyota(dot)ntt(at)gmail(dot)com> escreveu:

> At Wed, 10 Feb 2021 19:54:46 -0300, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
> wrote in
> > Hi,
> >
> > Per Coverity.
> >
> > The functions ExecGetInsertedCols and ExecGetUpdatedCols at ExecUtils.c
> > only are safe to call if the variable "ri_RangeTableIndex" is != 0.
> >
> > Otherwise a possible Dereference after null check (FORWARD_NULL) can be
> > raised.
>
> As it turns out, it's a false positive. And perhaps we don't want to
> take action just to satisfy the static code analyzer.
>
>
> The coment in ExecGetInsertedCols says:
>
> > /*
> > * The columns are stored in the range table entry. If this ResultRelInfo
> > * doesn't have an entry in the range table (i.e. if it represents a
> > * partition routing target), fetch the parent's RTE and map the columns
> > * to the order they are in the partition.
> > */
> > if (relinfo->ri_RangeTableIndex != 0)
> > {
>
> This means that any one of the two is always usable here. AFAICS,
> actually, ri_RangeTableIndex is non-zero for partitioned (=leaf) and
> non-partitoned relations and ri_RootResultRelInfo is non-null for
> partitioned (parent or intermediate) relations (since they don't have
> a coressponding range table entry).
>
> The only cases where both are 0 and NULL are trigger-use, which is
> unrelated to the code path.
>
This is a case where it would be worth an assertion.
What do you think?

regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message er 2021-02-12 16:30:31 Re: logical replication seems broken
Previous Message Zhihong Yu 2021-02-12 16:09:56 Re: Why do we have MakeSingleTupleTableSlot instead of not using MakeTupleTableSlot?