php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57538 int != long for zend_parse_parameters() on 64-bit architectures
Submitted: 2007-02-20 12:32 UTC Modified: 2007-03-18 16:33 UTC
From: joy at entuzijast dot net Assigned: mbretter (profile)
Status: Closed Package: radius (PECL)
PHP Version: 5.2.0 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: joy at entuzijast dot net
New email:
PHP Version: OS:

 

 [2007-02-20 12:32 UTC] joy at entuzijast dot net 
Description:
------------
On a machine running PHP5 on a Debian GNU/Linux installation within a Xen child, I ran into a strange problem with the PHP RADIUS extension whereby all connections to the local RADIUS server would instantly fail with "No valid RADIUS responses received", regardless of settings.

The problem seems to be that zend_parse_parameters() is very sensitive to its integer data types - you can't seem to write 'l's (longs) into ints.

Given that I also saw what happens if one sets timeout to 0, I also made the code barf at it. I don't believe anyone has a RADIUS server which answers within 0 microseconds. :)

Thanks in advance.


Reproduce code:
---------------
--- radius.c.orig       2003-11-17 20:45:00.000000000 +0100
+++ radius.c    2007-02-20 18:06:48.000000000 +0100
@@ -239,7 +239,8 @@
 PHP_FUNCTION(radius_add_server)
 {
        char *hostname, *secret;
-       int hostname_len, secret_len, port, timeout, maxtries;
+       int hostname_len, secret_len;
+       long port, timeout, maxtries;
        radius_descriptor *raddesc;
        zval *z_radh;

@@ -251,6 +252,11 @@
                return;
        }

+       if (timeout == 0) {
+              zend_error(E_ERROR, "Null timeout not acceptable");
+              RETURN_FALSE;
+        }
+
        ZEND_FETCH_RESOURCE(raddesc, radius_descriptor *, &z_radh, -1, "rad_handle", le_radius);

        if (rad_add_server(raddesc->radh, hostname, port, secret, timeout, maxtries) == -1) {

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-02-21 17:53 UTC] joy at entuzijast dot net 
The architecture was x86_64, by the way - sounds like the 64-bit nature of that architecture might be the issue there, since sizeof(long) is 8, while sizeof(int) is 4. I guess the zend_parse_parameters() is being careful to avoid writing anything (other than 0) into a variable of a smaller size than intended.
 [2007-02-26 13:30 UTC] michael at bretterklieber dot com 
hmm, looks like you're right regarding the 64 bit issue.
AFAIK 0 timeouts are handled by the underlaying radius library.
I'll try to fix this ASAP.
 [2007-02-26 15:32 UTC] joy at entuzijast dot net 
I pondered whether it's better to address timeout=0 issue in there or in the library; the library doesn't actually handle it, either.

The rad_add_server() function, radlib.c line 288, just copies the given timeout value without checking its value. You can easily move the semantic error handling over there if you prefer.
 [2007-03-18 16:33 UTC] michael at bretterklieber dot com 
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 19:01:30 2024 UTC