[sr-dev] db_free_columns and freeing column name

Chris Double chris.double at double.co.nz
Sun Aug 30 12:26:45 CEST 2015


This question relates to the commit in
http://lists.sip-router.org/pipermail/sr-dev/2015-August/030514.html

The db1_res_1 structure stores a string for the column names in the
query. The commit in the email referenced above fixed an issue in the
postgres backend where it was storing an internal postgres pointer in
the result structure but by the time the results were used in sqlops a
PQclear had been performed leaving that pointer dangling. Eventually a
use after free occurs.

The fix in the commit is to copy the column name into a pkg_malloc'd
area. The question I have is where should this be free'd.  I thought
db_free_columns in lib/srdb1/db_res.c would be the place. In that
function it frees the column str object (RES_NAMES(_r)[col]) but not
the string char* (RES_NAMES(_r)[col]->s).

Changing that function to free the string would seem to be the right
fix - is it free'd anywhere else that I'm missing?

Looking at the other database backends to work out whether they store
anything there that needs to be free'd shows similar issues to the
postgres one that was fixed in the commit referenced earlier:

db_berkeley: Uses a pointer to internal database results
db_mongodb: Uses a pointer to internal database results
db_mysql: Uses a pointer to internal database results
db_text: Uses a pointer to internal database results
db_unixodbc: Uses a pointer to a stack variable

The other backends (oracle, sqlite) seem to do the same as the fix
made to the postgres backend.

The unixodbc backend seem to have a dangling pointer into the stack
which is problematic. Should these DB backends be changed to copy the
column name instead of storing an internal pointer?  If so, is
db_free_columns the correct place to free that memory?

Is there anywhere else that stores column name data in results which
might need to be modified?

-- 
http://bluishcoder.co.nz



More information about the sr-dev mailing list