Re: Possible null pointer dereference in afterTriggerAddEvent() - Mailing list pgsql-hackers

From Alexander Kuznetsov
Subject Re: Possible null pointer dereference in afterTriggerAddEvent()
Date
Msg-id e1592981-c38c-49b1-ae30-a4f66e58863b@altlinux.org
Whole thread Raw
In response to Re: Possible null pointer dereference in afterTriggerAddEvent()  (Alexander Kuznetsov <kuznetsovam@altlinux.org>)
Responses Re: Possible null pointer dereference in afterTriggerAddEvent()
List pgsql-hackers
Hello,

is there anything else we can help with or discuss in order to apply this fix?

26.07.2024 12:16, Alexander Kuznetsov пишет:
> 25.07.2024 20:07, Alvaro Herrera wrote:
>> Maybe for sanity (and perhaps for Svace compliance) we could do it the
>> other way around, i.e. by testing events->tail for nullness instead of
>> events->head, then add the assertion:
>>
>>         if (events->tail == NULL)
>>         {
>>             Assert(events->head == NULL);
>>             events->head = chunk;
>>         }
>>         else
>>             events->tail->next = chunk;
>>
>> This way, it's not wholly redundant.
> Thanks for your response!
> I agree with the proposed changes and have updated the patch accordingly. Version 2 is attached.
>> That said, I'm not sure we actually *need* to change this.
> I understand and partly agree. But it appears that with these changes, the dereference of a null pointer is
impossibleeven in builds where assertions are disabled. Previously, this issue could theoretically occur. Consequently,
thesechanges slightly enhance overall security.
 
> 

-- 
Best regards,
Alexander Kuznetsov



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Support Int64 GUCs
Next
From: Alexander Kuznetsov
Date:
Subject: Re: Detect buffer underflow in get_th()