Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c)

Ranier Vilela <ranier.vf@gmail.com>

From: Ranier Vilela <ranier.vf@gmail.com>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2024-05-22T18:28:48Z
Lists: pgsql-hackers

Attachments

Em qua., 22 de mai. de 2024 às 13:09, Ranier Vilela <ranier.vf@gmail.com>
escreveu:

> Em qua., 22 de mai. de 2024 às 11:44, Ranier Vilela <ranier.vf@gmail.com>
> escreveu:
>
>> Hi.
>>
>> Per Coverity.
>>
>> 2. returned_null: SearchSysCacheAttName returns NULL (checked 20 out of
>> 21 times).
>> 3. var_assigned: Assigning: ptup = NULL return value from
>> SearchSysCacheAttName.
>>  964                ptup = SearchSysCacheAttName(relid, attname);
>> CID 1545986: (#1 of 1): Dereference null return value (NULL_RETURNS)
>> 4. dereference: Dereferencing ptup, which is known to be NULL.
>>
>> The functions SearchSysCacheAttNum and SearchSysCacheAttName,
>> need to have the result checked.
>>
>> The commit 5091995
>> <https://github.com/postgres/postgres/commit/509199587df73f06eda898ae13284292f4ae573a>,
>> left an oversight.
>>
>> Fixed by the patch attached, a change of style, unfortunately, was
>> necessary.
>>
> v1 Attached, fix wrong column variable name in error report.
>
1. Another concern is the function *get_partition_ancestors*,
which may return NIL, which may affect *llast_oid*, which does not handle
NIL entries.

2. Is checking *relispartition* enough?
There a function *check_rel_can_be_partition*
(src/backend/utils/adt/partitionfuncs.c),
which performs a much more robust check, would it be worth using it?

With the v2 attached, 1 is handled, but, in this case,
will it be the most correct?

best regards,
Ranier Vilela

Commits

  1. Fix potential NULL pointer dereference in getIdentitySequence()

  2. Fix assorted bugs related to identity column in partitioned tables