Red Hat Bugzilla – Bug 80485
Postgres ODBC lib Crashes in free(). Possible Buffer Overflow.
Last modified: 2007-04-18 12:49:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
I work for a small software development firm and we are wanting to offer a
turn-key solution which includes a small server, RH8, and our software.
However, when we try to install our software on a stock RH8 install php
segfaults. This also happens when all updates are applied. The installation
works on RH 7.3.
Our application is written in PHP. During the installation a PHP script opens a
file that contains the database CREATE TABLE statements necessary for creating
our database. The script reads and executes these statements. However, on RH8
it executes the first, then segfaults before executing the second. The problem
appears to be in the libodbcpsql.so library. I can reproduce it without the web
server by executing the php binary from the command line. I have a stack trace
from gdb that points to the Postgres ODBC library.
I can furnish the stack trace, the php script that opens the DDL files, the DDL
file itself, and the error message received in Apaches error_log file.
Like I said, it works under RH7.3. I've tried 3 different workstations with RH8
and they all segfault identically. I can walk you through a reproduction if you
Stack Trace: gdb php
(gdb) r run_ddl.php
Starting program: /usr/bin/php run_ddl.php
(no debugging symbols found)...[New Thread 8192 (LWP 2568)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 2568)]
0x42074a1a in free () from /lib/i686/libc.so.6
#0 0x42074a1a in free () from /lib/i686/libc.so.6
#1 0x40aa7c48 in TL_Destructor () from /usr/lib/libodbcpsql.so
#2 0x40aa306f in QR_Destructor () from /usr/lib/libodbcpsql.so
#3 0x40aa644f in PG_SQLFreeStmt () from /usr/lib/libodbcpsql.so
#4 0x40aa64c7 in SQLFreeStmt () from /usr/lib/libodbcpsql.so
#5 0x40961261 in SQLFreeEnv () from /usr/lib/libodbc.so.1
#6 0x40961923 in SQLFreeStmt () from /usr/lib/libodbc.so.1
#7 0x408a6050 in _free_odbc_result () from /usr/lib/php4/odbc.so
#8 0x08140202 in list_entry_destructor ()
#9 0x0813ea8a in zend_hash_del_key_or_index ()
#10 0x0813ff51 in _zend_list_delete ()
#11 0x408aa870 in zif_odbc_close () from /usr/lib/php4/odbc.so
#12 0x08152f6c in execute ()
#13 0x08152cdd in execute ()
#14 0x0813a186 in zend_execute_scripts ()
#15 0x080703ca in php_execute_script ()
#16 0x0806d4a8 in main ()
#17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run php
2. Pass run_ddl.php to executable (or call from apache)
3. Watch boobery.
Actual Results: Segmentation fault in free(). Thats bad news.
Expected Results: Run to completion as it does on RH 7.3
I'm marking this as a security bug. Possible buffer overflow, and since the
infected app is network-centric the possibilities of a remote root exploit are
This is a PostgreSQL ODBC related bug not unixODBC. We'll
take a look at it once it's in its proper place.
So is this going to get fixed? I really don't want to ship the product using mysql.
Andrew, please handle.
What versions of the various components are you running (unixODBC, PHP, and most
importantly PostgreSQL)? There was an erratum for PostgreSQL not too long ago
and I'm wondering if it was fixed by that.
Assigning to me (for posterity).
Need more info as requested.
Nope, the newest Postgres RPM via RHN didn't fix it.
I cannot duplicate the problem without seeing the actual PHP. I realise that
you may not want to attach your entire script, but do you think you can isolate
the section that is causing the problem?
Did you get a chance to isolate the portion of the script that's causing the
problem? I think you mentioned that it's only CREATE DATABASE statements so if
that's the case, can I see them? I would really like to duplicate this here so
that I can figure out where the problem lies.
This has been open for 3 months without a response from reporter, therefore
closing. If you have any more information for Andrew that can help him
reproduce this bug please reopen it.