Re: BUG #14928: Unchecked SearchSysCacheCopy1() return value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: bianpan2016(at)163(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14928: Unchecked SearchSysCacheCopy1() return value
Date: 2017-11-28 00:25:49
Message-ID: 19181.1511828749@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2017/11/27 18:13, bianpan2016(at)163(dot)com wrote:
>> Function SearchSysCacheCopy1() may return a NULL pointer if there is no
>> enough memory. But in function ATExecDetachPartition(), its return value is
>> not checked, which may result in NULL dereference (see line 13818).

> Thanks for the report. Attached a patch that adds a check that tuple is
> valid before trying to dereference it.

Pushed. Checking other SearchSysCache calls in these two files, I noted
a third instance of the same problem in StorePartitionKey(). However,
looking closer, StorePartitionKey never does anything at all with the
result of its SearchSysCache1(PARTRELID, ...) lookup, including never
releasing the syscache reference. How is it that we don't get refcount
leak warnings? I guess that must prove that that lookup always fails,
which is not too surprising since it seems to be against the partition
key info that we haven't stored yet. Anyway, I just diked that one
out, since it's clearly useless.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2017-11-28 00:35:46 Re: BUG #14929: Unchecked AllocateDir() return value in restoreTwoPhaseData()
Previous Message Andres Freund 2017-11-27 22:10:42 Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop