Re: BUG #14928: Unchecked SearchSysCacheCopy1() return value
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: bianpan2016@163.com, pgsql-bugs@postgresql.org
Date: 2017-11-27T10:21:32Z
Lists: pgsql-bugs
Attachments
- syscache-check-tuple-tablecmds.patch (text/plain) patch
On 2017/11/27 18:13, bianpan2016@163.com wrote: > The following bug has been logged on the website: > > Bug reference: 14928 > Logged by: Pan Bian > Email address: bianpan2016@163.com > PostgreSQL version: 10.1 > Operating system: Linux > Description: > > File: postgresql-10.1/src/backend/commands/tablecmds.c > Function: ATExecDetachPartition > Line: 13816 > > 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). > > For your convenience, I copy and paste related codes as follows. > > 13815 classRel = heap_open(RelationRelationId, RowExclusiveLock); > 13816 tuple = SearchSysCacheCopy1(RELOID, > 13817 > ObjectIdGetDatum(RelationGetRelid(partRel))); > 13818 Assert(((Form_pg_class) GETSTRUCT(tuple))->relispartition); > 13819 > 13820 (void) SysCacheGetAttr(RELOID, tuple, > Anum_pg_class_relpartbound, > 13821 &isnull); > 13822 Assert(!isnull); Thanks for the report. Attached a patch that adds a check that tuple is valid before trying to dereference it. Thanks, Amit
Commits
-
Fix assorted syscache lookup sloppiness in partition-related code.
- cb03fa33aeae 11.0 landed
- 64487044966d 10.2 landed