Re: [PATCH] FIx explicit null dereference pointer (nbtree.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] FIx explicit null dereference pointer (nbtree.c)
Date: 2020-04-23 01:28:11
Message-ID: CAEudQAqn7_XtkH3k75KL2e8fOiFe+OAVc57WyZg416f74RR2kQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qua., 22 de abr. de 2020 às 21:24, Peter Geoghegan <pg(at)bowt(dot)ie> escreveu:

> On Wed, Apr 22, 2020 at 3:55 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> > per Coverity.
>
> Some Postgres hackers have access to a dedicated coverity
> installation, and this issue has probably already been dismissed.
>
I will take a note.

>
> > 1. assign_zero: Assigning: opaque = NULL.
> > 2. Condition buf < 0, taking true branch.
> > 3. Condition !(((PageHeader)page)->pd_upper == 0), taking false branch.
> > 4. Condition blkno != orig_blkno, taking true branch.
> > 5. Condition _bt_page_recyclable(page), taking false branch.
> > CID 1314742 (#2 of 2): Explicit null dereferenced (FORWARD_NULL)
> > 6. var_deref_op: Dereferencing null pointer opaque.
>
> This is a false positive. btvacuumpage() is supposed to be a recursive
> function, but in practice the only caller always uses the same block
> number for both blkno and orig_blkno -- the tail recursion is actually
> implemented using goto/a loop.
>
This means that it is impossible for these conditions described by Coverity
to happen on the first call, when the var opaque is NULL.

regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-04-23 02:01:03 Re: Parallel Append can break run-time partition pruning
Previous Message Peter Geoghegan 2020-04-23 01:05:47 Re: xid wraparound danger due to INDEX_CLEANUP false