Re: Unlikely-to-happen crash in ecpg driver caused by NULL-pointer check not done

On 02/03/2015 09:28 AM, Michael Paquier wrote:
> Hi all,
>
> In ecpg_add_mem of memory.c, we use ecpg_alloc but there is actually
> no NULL-pointer check. If an OOM shows up exactly at this point, this
> is likely to cause a crash. Attached patch adds some extra processing
> to ecpg_add_mem to check if the allocation fails, and to fail properly
> if an OOM appears.

> --- a/src/interfaces/ecpg/ecpglib/descriptor.c
> +++ b/src/interfaces/ecpg/ecpglib/descriptor.c
> @@ -440,7 +440,12 @@ ECPGget_desc(int lineno, const char *desc_name, int index,...)
>                                                 return false;
>                                         }
>                                         *(void **) var = mem;
> -                                       ecpg_add_mem(mem, lineno);
> +                                       if (!ecpg_add_mem(mem, lineno))
> +                                       {
> +                                               ecpg_free(mem);
> +                                               va_end(args);
> +                                               return false;
> +                                       }
>                                         var = mem;
>                                 }

Hmm. Since the ecpg_add_mem call is done after setting (*(void **) var), 
that's left to point to already-free'd memory. The other call sites have 
a similar issue. I haven't analyzed the code to check if that's harmless 
or not, but seems better to not do that.

In ecpg_add_mem, the ecpg_raise() call is unnecessary, since ecpg_alloc 
already does that on failure.

(It would be less error-prone to have an ecpg_alloc_auto() function that 
combines ecpg_alloc+ecpg_add_mem in one call.)

> /* Here are some methods used by the lib. */
>
> /* Returns a pointer to a string containing a simple type name. */
> bool        ecpg_add_mem(void *ptr, int lineno);
>
> bool ecpg_get_data(const PGresult *, int, int, int, enum ECPGttype type,
>               enum ECPGttype, char *, char *, long, long, long,
>               enum ARRAY_TYPE, enum COMPAT_MODE, bool);

That second comment is completely bogus. It's not this patch's fault, 
it's been like that forever, but just happened to notice..

- Heikki