Horton

Re: Missing NULL check after calling ecpg_strdup

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Aleksander Alekseev <aleksander@tigerdata.com>
Cc: pgsql-hackers@lists.postgresql.org, Evgeniy Gorbanev <gorbanyoves@basealt.ru>
Date: 2025-07-12T03:23:07Z
Lists: pgsql-hackers 
On Fri, Jul 11, 2025 at 07:22:36PM +0300, Aleksander Alekseev wrote:
> The patch looks correct, but I believe it's incomplete. It misses
> several other places where ecpg_strdup() is called without proper
> checks. A correct patch would look like the one attached.
> 
> While working on it I noticed a potentially problematic strcmp call,
> marked with XXX in the patch. I didn't address this issue in v2.
> 
> Thoughts?

The semantics that I'm finding really annoying is the fact that
ecpg_strdup() is OK to assume that a NULL input is valid to handle, so
there is no way to make the difference between what should be an
actual error and what should be valid, leading to more confusion
because "realname" can be NULL.

Should we actually check sqlca_t more seriously if failing one of the
strdup calls used for the port, host, etc. when attempting the
connection?  The ecpg_log() assumes that a NULL value equals a
<DEFAULT>, which would be wrong if we failed one of these allocations
on OOM.
--
Michael

Commits

  1. ecpg: Improve error detection around ecpg_strdup()

  2. ecpg: Fix NULL pointer dereference during connection lookup