Re: Ask for two questions on psqlodbc

Dear all，

According to Fortify analysis，I found that some other malloc results could not be judged. It is also likely to produce a Null Dereference.

Details are as follows :
---------------------------------------------------------------
psqlodbc.h:433: in STRN_TO_NAME()
432 (the_name).name = malloc((n) + 1); \
433 memcpy((the_name).name, str, (n)); \
---------------------------------------------------------------
Here，if malloc failed，the returned name should be NULL.The subsequent memcpy operation had the potential to produce Null Dereference. 
There are two similar situations:
---------------------------------------------------------------
dlg_specific.c:1577: in decode()
1572 outs = (char *) malloc(ilen + 1);
1577 outs[o++] = ' ';
---------------------------------------------------------------
---------------------------------------------------------------
multibyte.c:186: in check_client_encoding()
185 rptr = malloc(len + 1);
186 memcpy(rptr, sptr, len);
---------------------------------------------------------------

I'am not sure if they are really bugs, because i'am not so familiar with psqlodbc's code.
Could you please give your point of view?
The attachments are related codes.
Thank you very much.

Best wishes~
Sincerely yours, 
pluto.cobain

> Date: Thu, 3 Jul 2014 23:35:33 +0900
> From: inoue@tpf.co.jp
> To: pluto_cbin@outlook.com; pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Ask for two questions on psqlodbc
>
> Hi,
>
> (2014/07/02 18:09), cobainpluto wrote:
> > Dear all，
> > Recently, I used Static Code Analyzer(Fortify) to analyze
> > psqlodbc-09.03.0300 codes, and found two potential Memory Leak
> > problems in qresult.c file.
> >
> > Details are as follows :
> > 1.Potential Memory Leak problem
> > qresult.c:962: in QR_next_tuple()
> > 962 mres = CC_send_query(conn, movecmd, NULL, 0, stmt);
> > There is a dynamically allocated memory in CC_send_query_append(...).
> > If follow the below path, from here to RETURN (-1), the applied memory
> > space is not free, so it is possiblehas to generate Memory
> > Leak.
> > ---------------------------------------------------------------
> > qresult.c:963 - BranchNotTaken : Branch not taken: (mres != 0)
> > qresult.c:971 - BranchTaken : Branch taken: (sscanf(mres->command, "MOVE
> > %lu", (&moved)) > 0)
> > qresult.c:974 - BranchTaken : Branch taken: (moved < movement)
> > qresult.c:993 - BranchTaken : Branch taken: (2 == self->move_direction)
> > qresult.c:998 - BranchTaken : Branch taken: (getNthValid(self, (<inline
> > expression> - 1), 4, self->move_offset, (&backpt)) < 0)
> > qresult.c:1004 - EndScope : RETURN(-1)
>
> It seems a memory leak.
> I would fix it.
>
> > ---------------------------------------------------------------
> >
> > 2、Potential Null Dereference problem
> > qresult.c:1691: in QR_read_a_tuple_from_db()
> > 1691 &this_keyset->blocknum, &this_keyset->offset);
> > qresult.c:1693: in QR_read_a_tuple_from_db()
> > 1693 this_keyset->oid = strtoul(buffer, NULL, 10);
> > Here reference to the this_keyset.
> > If follow the below path,value of this_keyset is always NULL before
> > referring to this_keyset, so it is possiblehas to generate Null
> > Dereference possible.
> > ---------------------------------------------------------------
> > qresult.c:1571 - Assigned null : KeySet *this_keyset = NULL;
> > qresult.c:1590 - BranchNotTaken : Branch not taken: (0 == (self->flags & 1))
> > qresult.c:1624 - BranchTaken : Branch taken: (field_lf < ci_num_fields)
> > qresult.c:1668 - BranchNotTaken : Branch not taken: (isnull == 0)
> > qresult.c:1676 - BranchTaken : Branch taken: (field_lf >= effective_cols)
> > qresult.c:1687 - BranchTaken : Branch taken: (field_lf >= effective_cols)
>
> Though I'm suspcious if it could occur, I would check it.
>
> Thanks.
> Hiroshi Inoue
>
>
> --
> Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-odbc