Re: Possible pointer dereference

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Gaetano Mendola <mendola(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible pointer dereference
Date: 2015-05-28 00:57:15
Message-ID: CAJrrPGdBnQdEUDGR+60D8h9thUD5DmhrrKUdVoU8ns+YM7iGiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 28, 2015 at 6:07 AM, Gaetano Mendola <mendola(at)gmail(dot)com> wrote:
> I'm playing with a static analyzer and it's giving out some real error
> analyzing postgresql code base like the following one
>
> src/backend/access/transam/commit_ts.c
> return *ts != 0 // line 321
> but a few line up (line 315) ts is checked for null, so either is not needed
> to check for null or *ts can lead to a null pointer dereference. Same
> happens a few line later lines 333 and 339

Thanks for providing detailed information.

The function "TransactionIdGetCommitTsData" is currently used only at
one place. The caller
always passes an valid pointer to this function. So there shouldn't be
a problem. But in future
if the same function is used at somewhere by passing the NULL pointer
then it leads to a crash.

By correcting the following way will solve the problem.

return ts ? (*ts != 0) : false; instead of retun *ts != 0;

Attached a patch for it.

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
commit_ts_fix.patch application/octet-stream 870 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2015-05-28 01:00:36 Re: Can we add syntax for references auto create index or not.
Previous Message Tom Lane 2015-05-28 00:45:45 Re: fsync-pgdata-on-recovery tries to write to more files than previously