Thread: Missing NULL check after calling ecpg_strdup

Hi!

In case of out_of_memory, the ecpg_strdup function may return NULL.
Checks should be added in src/interfaces/ecpg/ecpglib/execute.c.
Patch attached.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

--
Best regards,
Evgeniy  Gorbanev

Hi Evgeniy,

> In case of out_of_memory, the ecpg_strdup function may return NULL.
> Checks should be added in src/interfaces/ecpg/ecpglib/execute.c.
> Patch attached.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.

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?

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