|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #43861 suhosin patch detects heap overflow on mssql_free_result()
Submitted: 2008-01-16 01:03 UTC Modified: 2008-07-29 01:00 UTC
Avg. Score:4.9 ± 0.3
Reproduced:13 of 13 (100.0%)
Same Version:8 (61.5%)
Same OS:3 (23.1%)
From: skennedy at vcn dot com Assigned: fb-req-jani (profile)
Status: No Feedback Package: MSSQL related
PHP Version: 5.2.5 OS: FreeBSD 6.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
42 - 42 = ?
Subscribe to this entry?

 [2008-01-16 01:03 UTC] skennedy at vcn dot com
Getting an "ALERT - canary mismatch on efree() - heap overflow detected" error when running two certain queries.  This seems to be triggered when the second query runs.  The error indicates the mssql_free_result() is the offender, but it happens even when mssql_free_result() is omitted (however does not show the offending line number).  This bug is the similar, if not the same, as #40119.

Reproduce code:

Expected result:
To run without error and exit cleanly.

Actual result:
ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file '/usr/home/bwbuilders/test.php', line 33)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-01-22 15:54 UTC] kepi at orthank dot net
We have same problem with every sql query we tried:

$conn = odbc_connect("FreeTDS", "user", "name");
$query = "SELECT * FROM systypes";
$result = odbc_exec($conn,$query);

 ALERT - canary mismatch on efree() - heap overflow detected (attacker '', file '/var/www/test.php', line 3)
 [2008-01-27 16:46 UTC]
Can you please to run the script through valgrind without suhosin 
extension enabled.

 [2008-01-28 21:51 UTC] skennedy at vcn dot com
Apparently amd64/FreeBSD cannot run valgrind.  I get this when trying to install it:

===>  valgrind-352_7 is only for i386, while you are running amd64.*** Error code 1

Is there anything else that's amd64/FreeBSD friendly I can use?
 [2008-01-28 23:35 UTC]
Would be nice if you try it on some Linux machine.
 [2008-01-30 00:09 UTC] skennedy at vcn dot com
 [2008-01-30 01:09 UTC]
I know that Valgrind output looks scary, but that is actually a clean run.  The dlopen/dlclose stuff is normal.  Are you seeing the same warning on this setup?
 [2008-01-30 17:21 UTC] skennedy at vcn dot com

I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch.  The result: same exact error as on FreeBSD.

The original valgrind output I submitted was from the PHP installed via a Debian package.  So I recompiled my PHP again this time without Sushosin patch and ran valgrind again.  Updated output:

Let me know if you need me to do anything else.  Thanks.
 [2008-01-30 17:56 UTC]
Again, that valgrind output does not show an overflow.  Either the problem is being masked by the suhosin patch, or it is a false positive.  Trying removing the suhosin patch and do the valgrind check again.
 [2008-01-30 18:38 UTC] skennedy at vcn dot com
That valgrind output *is* without the Suhosin patch.

I was saying that I first compiled PHP w/ Suhosin patch to make sure it errors-out with the heap overflow as it does on my FreeBSD box and it did.  Then I compiled PHP again this time w/out Suhosin and ran the valgrind which is the output you see in the link.
 [2008-01-30 21:08 UTC]
Sometimes the Zend memory manager hides stuff as well. Could you please try disabling that by setting the "USE_ZEND_ALLOC" environment variable to 0? (Something like "export USE_ZEND_ALLOC=0" should do that). And then re-try to make a valgrind trace. Thanks!
 [2008-01-30 21:23 UTC] skennedy at vcn dot com
Okay, here is that:
 [2008-01-31 00:16 UTC]
Ok, there we go.  Looks like there is an off-by-one in there.  But looking at the PHP code, it seems ok.

int res_length = dbdatlen(mssql_ptr->link,offset);
res_buf = (unsigned char *) emalloc(res_length+1);
res_length = dbconvert(NULL,coltype(offset),dbdata(mssql_ptr->link,offset), res_length, SQLCHAR,res_buf,-1);
res_buf[res_length] = '\0';

So, we aren't going beyond the buffer, it is somewhere in the dbconvert() code writing to res_buf that is off.  Passing in a larger buffer would fix it, but it would be good to understand why dbdatlen() isn't returning the right length.  Is it an encoding issue?  One assumes single-byte encoding and the other multi-byte or something?

Looping in Frank to have a look.

 [2008-02-10 07:57 UTC] cxcxcxcx at gmail dot com
I have encountered a similar problem. When "select" contains 'smalldatetime' or 'datetime' columns.

I am using Debian Sid and php5 php5-sybase.
 [2008-02-10 14:50 UTC]
Can you please try a CVS snapshot on PHP 5.3.0 in about 4-5 hours. I've 
just applied a patch to the code that may fix your problem. 

Alternatively you can try the patch yourself from this URL;

 [2008-03-04 18:45 UTC] skennedy at vcn dot com
Sorry for not getting this done sooner.  I got a PHP 5.3 snapshot and compiled/installed it and ran it through valgrind with the USE_ZEND_ALLOC env var set to 0 and here is the output:
 [2008-07-21 20:45 UTC]
But did you apply the patch Ilia mentions above? Try again using current 5.3 snapshot. (and if that patch still applies, try it..)
btw. That last url to some output you posted is no longer valid..
 [2008-07-29 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 13 21:01:28 2024 UTC