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 would like. 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)] X-Powered-By: PHP/4.2.2 Content-type: text/html Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 2568)] 0x42074a1a in free () from /lib/i686/libc.so.6 (gdb) where #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): How reproducible: Always 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 Additional info: 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 there.
Hi, This is a PostgreSQL ODBC related bug not unixODBC. We'll take a look at it once it's in its proper place. Cheers, Patrick
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. unixODBC 2.2.3 PostgreSQL 7.2.3 PHP 4.2.2 Apache 2.0.40
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?
Matthew: 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.