#40600 [NEW]: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash)

[stas at FreeBSD dot org]

From: stas at FreeBSD dot org
Operating system: FreeBSD
PHP version: 5.2.1
PHP Bug Type: POSIX related
Bug description: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash)

Description:
------------
This module has problems with functions like getgrgid_r etc. It tries to
find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which obviously
fails, since trying to allocate (size_t)-1 bytes exceeds any limits.

Reproduce code:
---------------
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);

Expected result:
----------------
something meaningful


--
Edit bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]
--
Try a CVS snapshot (PHP 4.4): [url]http://bugs.php.net/fix.php?id=40600&r=trysnapshot44[/url]
Try a CVS snapshot (PHP 5.2): [url]http://bugs.php.net/fix.php?id=40600&r=trysnapshot52[/url]
Try a CVS snapshot (PHP 6.0): [url]http://bugs.php.net/fix.php?id=40600&r=trysnapshot60[/url]
Fixed in CVS: [url]http://bugs.php.net/fix.php?id=40600&r=fixedcvs[/url]
Fixed in release: [url]http://bugs.php.net/fix.php?id=40600&r=alreadyfixed[/url]
Need backtrace: [url]http://bugs.php.net/fix.php?id=40600&r=needtrace[/url]
Need Reproduce Script: [url]http://bugs.php.net/fix.php?id=40600&r=needscript[/url]
Try newer version: [url]http://bugs.php.net/fix.php?id=40600&r=oldversion[/url]
Not developer issue: [url]http://bugs.php.net/fix.php?id=40600&r=support[/url]
Expected behavior: [url]http://bugs.php.net/fix.php?id=40600&r=notwrong[/url]
Not enough info: [url]http://bugs.php.net/fix.php?id=40600&r=notenoughinfo[/url]
Submitted twice: [url]http://bugs.php.net/fix.php?id=40600&r=submittedtwice[/url]
register_globals: [url]http://bugs.php.net/fix.php?id=40600&r=globals[/url]
PHP 3 support discontinued: [url]http://bugs.php.net/fix.php?id=40600&r=php3[/url]
Daylight Savings: [url]http://bugs.php.net/fix.php?id=40600&r=dst[/url]
IIS Stability: [url]http://bugs.php.net/fix.php?id=40600&r=isapi[/url]
Install GNU Sed: [url]http://bugs.php.net/fix.php?id=40600&r=gnused[/url]
Floating point limitations: [url]http://bugs.php.net/fix.php?id=40600&r=float[/url]
No Zend Extensions: [url]http://bugs.php.net/fix.php?id=40600&r=nozend[/url]
MySQL Configuration Error: [url]http://bugs.php.net/fix.php?id=40600&r=mysqlcfg[/url]

[stas at FreeBSD dot org]

ID: 40600
User updated by: stas at FreeBSD dot org
Reported By: stas at FreeBSD dot org
Status: Open
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:

The patch itself:
----------------------------------------------------------------
--- posix.c.orig Fri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@

#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;

@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);

ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@

#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;

@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);

ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--------------------------------------------------------------


Previous Comments:
------------------------------------------------------------------------

[2007-02-22 23:32:39] stas at FreeBSD dot org

Description:
------------
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.

Reproduce code:
---------------
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);

Expected result:
----------------
something meaningful



------------------------------------------------------------------------


--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[tony2001@php.net]

ID: 40600
Updated by: [email]tony2001@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Open
+Status: Feedback
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:

+ if (grbuflen < 0)
+ grbuflen = 1024;

I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.


Previous Comments:
------------------------------------------------------------------------

[2007-02-22 23:34:54] stas at FreeBSD dot org

The patch itself:
----------------------------------------------------------------
--- posix.c.orig Fri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@

#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;

@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);

ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@

#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;

@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);

ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--------------------------------------------------------------

------------------------------------------------------------------------

[2007-02-22 23:32:39] stas at FreeBSD dot org

Description:
------------
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.

Reproduce code:
---------------
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);

Expected result:
----------------
something meaningful



------------------------------------------------------------------------


--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[stas at FreeBSD dot org]

ID: 40600
User updated by: stas at FreeBSD dot org
Reported By: stas at FreeBSD dot org
-Status: Feedback
+Status: Open
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

>It might be safe to do it on FreeBSD when you know for sure >that this

functionality is missing and it's safe to use 1K >buffer, but other
systems might behave differently.

This patch covers two problems:
1) The POSIX says that sysconf will return -1 on failure, thus the ( <
1) check is definitely incorrect
2) It's safe to use the buffer of any size (according to POSIX), since
you give the buffer length to these functions. They'll return error if
the buffer lenght isn't enough - it's better then give up on retriving
this info just in case the sysconf doesn't has these limit values.


Previous Comments:
------------------------------------------------------------------------

[2007-02-22 23:39:18] [email]tony2001@php.net[/email]

+ if (grbuflen < 0)
+ grbuflen = 1024;

I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.

------------------------------------------------------------------------

[2007-02-22 23:34:54] stas at FreeBSD dot org

The patch itself:
----------------------------------------------------------------
--- posix.c.orig Fri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@

#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;

@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);

ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@

#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;

@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);

ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--------------------------------------------------------------

------------------------------------------------------------------------

[2007-02-22 23:32:39] stas at FreeBSD dot org

Description:
------------
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.

Reproduce code:
---------------
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);

Expected result:
----------------
something meaningful



------------------------------------------------------------------------


--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[tony2001@php.net]

ID: 40600
Updated by: [email]tony2001@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Open
+Status: Feedback
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:

>This patch covers two problems:
>1) The POSIX says that sysconf will return -1 on failure,
> thus the ( < check is definitely incorrect

Oh? Care to elaborate?

>2) It's safe to use the buffer of any size (according to
> POSIX), since you give the buffer length to these
> functions.

Yeah, according to POSIX those functions must be implemented.
But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

I don't think it's any better to use hacks to workaround missing
FreeBSD functionality.



Previous Comments:
------------------------------------------------------------------------

[2007-02-23 10:47:13] stas at FreeBSD dot org

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

>It might be safe to do it on FreeBSD when you know for sure >that this

functionality is missing and it's safe to use 1K >buffer, but other
systems might behave differently.

This patch covers two problems:
1) The POSIX says that sysconf will return -1 on failure, thus the ( <
1) check is definitely incorrect
2) It's safe to use the buffer of any size (according to POSIX), since
you give the buffer length to these functions. They'll return error if
the buffer lenght isn't enough - it's better then give up on retriving
this info just in case the sysconf doesn't has these limit values.

------------------------------------------------------------------------

[2007-02-22 23:39:18] [email]tony2001@php.net[/email]

+ if (grbuflen < 0)
+ grbuflen = 1024;

I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.

------------------------------------------------------------------------

[2007-02-22 23:34:54] stas at FreeBSD dot org

The patch itself:
----------------------------------------------------------------
--- posix.c.orig Fri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@

#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;

@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);

ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@

#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;

@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);

ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--------------------------------------------------------------

------------------------------------------------------------------------

[2007-02-22 23:32:39] stas at FreeBSD dot org

Description:
------------
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.

Reproduce code:
---------------
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);

Expected result:
----------------
something meaningful



------------------------------------------------------------------------


--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[stas at FreeBSD dot org]

ID: 40600
User updated by: stas at FreeBSD dot org
Reported By: stas at FreeBSD dot org
-Status: Feedback
+Status: Open
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:

>>This patch covers two problems:
>>1) The POSIX says that sysconf will return -1 on failure,
>> thus the ( < check is definitely incorrect

>
>Oh? Care to elaborate?

Yeah... According to susv3:
"If name is an invalid value, sysconf() shall return -1 and set errno
to indicate the error. If the variable corresponding to name has no
limit, sysconf() shall return -1 without changing the value of errno.
Note that indefinite limits do not imply infinite limits; see
<limits.h>."

>>2) It's safe to use the buffer of any size (according to
>> POSIX), since you give the buffer length to these
>> functions.

>
>Yeah, according to POSIX those functions must be >implemented.
>But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

>I don't think it's any better to use hacks to workaround >missing

FreeBSD

> functionality.

Ok, agree. It's open to you.


Previous Comments:
------------------------------------------------------------------------

[2007-02-23 12:22:20] [email]tony2001@php.net[/email]

>This patch covers two problems:
>1) The POSIX says that sysconf will return -1 on failure,
> thus the ( < check is definitely incorrect

Oh? Care to elaborate?

>2) It's safe to use the buffer of any size (according to
> POSIX), since you give the buffer length to these
> functions.

Yeah, according to POSIX those functions must be implemented.
But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

I don't think it's any better to use hacks to workaround missing
FreeBSD functionality.


------------------------------------------------------------------------

[2007-02-23 10:47:13] stas at FreeBSD dot org

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

>It might be safe to do it on FreeBSD when you know for sure >that this

functionality is missing and it's safe to use 1K >buffer, but other
systems might behave differently.

This patch covers two problems:
1) The POSIX says that sysconf will return -1 on failure, thus the ( <
1) check is definitely incorrect
2) It's safe to use the buffer of any size (according to POSIX), since
you give the buffer length to these functions. They'll return error if
the buffer lenght isn't enough - it's better then give up on retriving
this info just in case the sysconf doesn't has these limit values.

------------------------------------------------------------------------

[2007-02-22 23:39:18] [email]tony2001@php.net[/email]

+ if (grbuflen < 0)
+ grbuflen = 1024;

I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.

------------------------------------------------------------------------

[2007-02-22 23:34:54] stas at FreeBSD dot org

The patch itself:
----------------------------------------------------------------
--- posix.c.orig Fri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@

#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;

@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);

ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@

#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;

@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);

ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--------------------------------------------------------------

------------------------------------------------------------------------

[2007-02-22 23:32:39] stas at FreeBSD dot org

Description:
------------
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.

Reproduce code:
---------------
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);

Expected result:
----------------
something meaningful



------------------------------------------------------------------------


--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[tony2001@php.net]

ID: 40600
Updated by: [email]tony2001@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Open
+Status: Feedback
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:

>Yeah... According to susv3:

Yes, I know that, thanks.
But that does not mean "if (buflen < 1)" is incorrect.
I don't think that zero buflen is a correct value (and even if it is,
it's useless).


Previous Comments:
------------------------------------------------------------------------

[2007-02-23 13:47:59] stas at FreeBSD dot org

>>This patch covers two problems:
>>1) The POSIX says that sysconf will return -1 on failure,
>> thus the ( < check is definitely incorrect

>
>Oh? Care to elaborate?

Yeah... According to susv3:
"If name is an invalid value, sysconf() shall return -1 and set errno
to indicate the error. If the variable corresponding to name has no
limit, sysconf() shall return -1 without changing the value of errno.
Note that indefinite limits do not imply infinite limits; see
<limits.h>."

>>2) It's safe to use the buffer of any size (according to
>> POSIX), since you give the buffer length to these
>> functions.

>
>Yeah, according to POSIX those functions must be >implemented.
>But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

>I don't think it's any better to use hacks to workaround >missing

FreeBSD

> functionality.

Ok, agree. It's open to you.

------------------------------------------------------------------------

[2007-02-23 12:22:20] [email]tony2001@php.net[/email]

>This patch covers two problems:
>1) The POSIX says that sysconf will return -1 on failure,
> thus the ( < check is definitely incorrect

Oh? Care to elaborate?

>2) It's safe to use the buffer of any size (according to
> POSIX), since you give the buffer length to these
> functions.

Yeah, according to POSIX those functions must be implemented.
But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

I don't think it's any better to use hacks to workaround missing
FreeBSD functionality.


------------------------------------------------------------------------

[2007-02-23 10:47:13] stas at FreeBSD dot org

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

>It might be safe to do it on FreeBSD when you know for sure >that this

functionality is missing and it's safe to use 1K >buffer, but other
systems might behave differently.

This patch covers two problems:
1) The POSIX says that sysconf will return -1 on failure, thus the ( <
1) check is definitely incorrect
2) It's safe to use the buffer of any size (according to POSIX), since
you give the buffer length to these functions. They'll return error if
the buffer lenght isn't enough - it's better then give up on retriving
this info just in case the sysconf doesn't has these limit values.

------------------------------------------------------------------------

[2007-02-22 23:39:18] [email]tony2001@php.net[/email]

+ if (grbuflen < 0)
+ grbuflen = 1024;

I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.

------------------------------------------------------------------------

[2007-02-22 23:34:54] stas at FreeBSD dot org

The patch itself:
----------------------------------------------------------------
--- posix.c.orig Fri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@

#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;

@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);

ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@

#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;

@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);

ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--------------------------------------------------------------

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[tony2001@php.net]

ID: 40600
Updated by: [email]tony2001@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Feedback
+Status: Assigned
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
-Assigned To:
+Assigned To: iliaa
New Comment:

Ilia, please take a look at this, IIRC you added those sysconf()
patches.


Previous Comments:
------------------------------------------------------------------------

[2007-02-23 13:55:02] [email]tony2001@php.net[/email]

>Yeah... According to susv3:

Yes, I know that, thanks.
But that does not mean "if (buflen < 1)" is incorrect.
I don't think that zero buflen is a correct value (and even if it is,
it's useless).

------------------------------------------------------------------------

[2007-02-23 13:47:59] stas at FreeBSD dot org

>>This patch covers two problems:
>>1) The POSIX says that sysconf will return -1 on failure,
>> thus the ( < check is definitely incorrect

>
>Oh? Care to elaborate?

Yeah... According to susv3:
"If name is an invalid value, sysconf() shall return -1 and set errno
to indicate the error. If the variable corresponding to name has no
limit, sysconf() shall return -1 without changing the value of errno.
Note that indefinite limits do not imply infinite limits; see
<limits.h>."

>>2) It's safe to use the buffer of any size (according to
>> POSIX), since you give the buffer length to these
>> functions.

>
>Yeah, according to POSIX those functions must be >implemented.
>But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

>I don't think it's any better to use hacks to workaround >missing

FreeBSD

> functionality.

Ok, agree. It's open to you.

------------------------------------------------------------------------

[2007-02-23 12:22:20] [email]tony2001@php.net[/email]

>This patch covers two problems:
>1) The POSIX says that sysconf will return -1 on failure,
> thus the ( < check is definitely incorrect

Oh? Care to elaborate?

>2) It's safe to use the buffer of any size (according to
> POSIX), since you give the buffer length to these
> functions.

Yeah, according to POSIX those functions must be implemented.
But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

I don't think it's any better to use hacks to workaround missing
FreeBSD functionality.


------------------------------------------------------------------------

[2007-02-23 10:47:13] stas at FreeBSD dot org

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

>It might be safe to do it on FreeBSD when you know for sure >that this

functionality is missing and it's safe to use 1K >buffer, but other
systems might behave differently.

This patch covers two problems:
1) The POSIX says that sysconf will return -1 on failure, thus the ( <
1) check is definitely incorrect
2) It's safe to use the buffer of any size (according to POSIX), since
you give the buffer length to these functions. They'll return error if
the buffer lenght isn't enough - it's better then give up on retriving
this info just in case the sysconf doesn't has these limit values.

------------------------------------------------------------------------

[2007-02-22 23:39:18] [email]tony2001@php.net[/email]

+ if (grbuflen < 0)
+ grbuflen = 1024;

I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[iliaa@php.net]

ID: 40600
Updated by: [email]iliaa@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Assigned
+Status: Bogus
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
[url]http://www.php.net/manual/[/url] and the instructions on how to report
a bug at [url]http://bugs.php.net/how-to-report.php[/url]

The current code is fine, we should not hardcode buffer sizes
if they cannot be retrieved, this could lead to exploitable
situations. Also if the return buffer length of 0 it probably
indicates a problem.


Previous Comments:
------------------------------------------------------------------------

[2007-02-23 14:07:38] [email]tony2001@php.net[/email]

Ilia, please take a look at this, IIRC you added those sysconf()
patches.

------------------------------------------------------------------------

[2007-02-23 13:55:02] [email]tony2001@php.net[/email]

>Yeah... According to susv3:

Yes, I know that, thanks.
But that does not mean "if (buflen < 1)" is incorrect.
I don't think that zero buflen is a correct value (and even if it is,
it's useless).

------------------------------------------------------------------------

[2007-02-23 13:47:59] stas at FreeBSD dot org

>>This patch covers two problems:
>>1) The POSIX says that sysconf will return -1 on failure,
>> thus the ( < check is definitely incorrect

>
>Oh? Care to elaborate?

Yeah... According to susv3:
"If name is an invalid value, sysconf() shall return -1 and set errno
to indicate the error. If the variable corresponding to name has no
limit, sysconf() shall return -1 without changing the value of errno.
Note that indefinite limits do not imply infinite limits; see
<limits.h>."

>>2) It's safe to use the buffer of any size (according to
>> POSIX), since you give the buffer length to these
>> functions.

>
>Yeah, according to POSIX those functions must be >implemented.
>But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

>I don't think it's any better to use hacks to workaround >missing

FreeBSD

> functionality.

Ok, agree. It's open to you.

------------------------------------------------------------------------

[2007-02-23 12:22:20] [email]tony2001@php.net[/email]

>This patch covers two problems:
>1) The POSIX says that sysconf will return -1 on failure,
> thus the ( < check is definitely incorrect

Oh? Care to elaborate?

>2) It's safe to use the buffer of any size (according to
> POSIX), since you give the buffer length to these
> functions.

Yeah, according to POSIX those functions must be implemented.
But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

I don't think it's any better to use hacks to workaround missing
FreeBSD functionality.


------------------------------------------------------------------------

[2007-02-23 10:47:13] stas at FreeBSD dot org

- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;

>It might be safe to do it on FreeBSD when you know for sure >that this

functionality is missing and it's safe to use 1K >buffer, but other
systems might behave differently.

This patch covers two problems:
1) The POSIX says that sysconf will return -1 on failure, thus the ( <
1) check is definitely incorrect
2) It's safe to use the buffer of any size (according to POSIX), since
you give the buffer length to these functions. They'll return error if
the buffer lenght isn't enough - it's better then give up on retriving
this info just in case the sysconf doesn't has these limit values.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[stas at FreeBSD dot org]

ID: 40600
User updated by: stas at FreeBSD dot org
Reported By: stas at FreeBSD dot org
Status: Bogus
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:

> The current code is fine, we should not hardcode buffer > sizes

if they cannot be retrieved, this could lead to > exploitable
situations. Also if the return buffer length of > 0 it probably
indicates a problem.

1) According to POSIX it's not a problem
2) Besides that one check is missing (take a look at patch), so you're
effectively trying to malloc (size_t)-1 bytes on FreeBSD currently,
which leads to crash.


Previous Comments:
------------------------------------------------------------------------

[2007-02-23 23:53:25] [email]iliaa@php.net[/email]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
[url]http://www.php.net/manual/[/url] and the instructions on how to report
a bug at [url]http://bugs.php.net/how-to-report.php[/url]

The current code is fine, we should not hardcode buffer sizes
if they cannot be retrieved, this could lead to exploitable
situations. Also if the return buffer length of 0 it probably
indicates a problem.

------------------------------------------------------------------------

[2007-02-23 14:07:38] [email]tony2001@php.net[/email]

Ilia, please take a look at this, IIRC you added those sysconf()
patches.

------------------------------------------------------------------------

[2007-02-23 13:55:02] [email]tony2001@php.net[/email]

>Yeah... According to susv3:

Yes, I know that, thanks.
But that does not mean "if (buflen < 1)" is incorrect.
I don't think that zero buflen is a correct value (and even if it is,
it's useless).

------------------------------------------------------------------------

[2007-02-23 13:47:59] stas at FreeBSD dot org

>>This patch covers two problems:
>>1) The POSIX says that sysconf will return -1 on failure,
>> thus the ( < check is definitely incorrect

>
>Oh? Care to elaborate?

Yeah... According to susv3:
"If name is an invalid value, sysconf() shall return -1 and set errno
to indicate the error. If the variable corresponding to name has no
limit, sysconf() shall return -1 without changing the value of errno.
Note that indefinite limits do not imply infinite limits; see
<limits.h>."

>>2) It's safe to use the buffer of any size (according to
>> POSIX), since you give the buffer length to these
>> functions.

>
>Yeah, according to POSIX those functions must be >implemented.
>But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

>I don't think it's any better to use hacks to workaround >missing

FreeBSD

> functionality.

Ok, agree. It's open to you.

------------------------------------------------------------------------

[2007-02-23 12:22:20] [email]tony2001@php.net[/email]

>This patch covers two problems:
>1) The POSIX says that sysconf will return -1 on failure,
> thus the ( < check is definitely incorrect

Oh? Care to elaborate?

>2) It's safe to use the buffer of any size (according to
> POSIX), since you give the buffer length to these
> functions.

Yeah, according to POSIX those functions must be implemented.
But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

I don't think it's any better to use hacks to workaround missing
FreeBSD functionality.


------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[stas at FreeBSD dot org]

ID: 40600
User updated by: stas at FreeBSD dot org
Reported By: stas at FreeBSD dot org
-Status: Bogus
+Status: Open
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:

The bug is still here.


Previous Comments:
------------------------------------------------------------------------

[2007-02-24 09:03:50] stas at FreeBSD dot org

> The current code is fine, we should not hardcode buffer > sizes

if they cannot be retrieved, this could lead to > exploitable
situations. Also if the return buffer length of > 0 it probably
indicates a problem.

1) According to POSIX it's not a problem
2) Besides that one check is missing (take a look at patch), so you're
effectively trying to malloc (size_t)-1 bytes on FreeBSD currently,
which leads to crash.

------------------------------------------------------------------------

[2007-02-23 23:53:25] [email]iliaa@php.net[/email]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
[url]http://www.php.net/manual/[/url] and the instructions on how to report
a bug at [url]http://bugs.php.net/how-to-report.php[/url]

The current code is fine, we should not hardcode buffer sizes
if they cannot be retrieved, this could lead to exploitable
situations. Also if the return buffer length of 0 it probably
indicates a problem.

------------------------------------------------------------------------

[2007-02-23 14:07:38] [email]tony2001@php.net[/email]

Ilia, please take a look at this, IIRC you added those sysconf()
patches.

------------------------------------------------------------------------

[2007-02-23 13:55:02] [email]tony2001@php.net[/email]

>Yeah... According to susv3:

Yes, I know that, thanks.
But that does not mean "if (buflen < 1)" is incorrect.
I don't think that zero buflen is a correct value (and even if it is,
it's useless).

------------------------------------------------------------------------

[2007-02-23 13:47:59] stas at FreeBSD dot org

>>This patch covers two problems:
>>1) The POSIX says that sysconf will return -1 on failure,
>> thus the ( < check is definitely incorrect

>
>Oh? Care to elaborate?

Yeah... According to susv3:
"If name is an invalid value, sysconf() shall return -1 and set errno
to indicate the error. If the variable corresponding to name has no
limit, sysconf() shall return -1 without changing the value of errno.
Note that indefinite limits do not imply infinite limits; see
<limits.h>."

>>2) It's safe to use the buffer of any size (according to
>> POSIX), since you give the buffer length to these
>> functions.

>
>Yeah, according to POSIX those functions must be >implemented.
>But they are not.

>it's better then give up on retriving this info just in
>case the sysconf doesn't has these limit values.

>I don't think it's any better to use hacks to workaround >missing

FreeBSD

> functionality.

Ok, agree. It's open to you.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[iliaa@php.net]

ID: 40600
Updated by: [email]iliaa@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Open
+Status: Bogus
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:

buflen check disallows values that are less then 1, so how
will you ever allocate a negative value?

RETURN_FALSE will terminate the function.


Previous Comments:
------------------------------------------------------------------------

[2007-02-25 23:04:42] stas at FreeBSD dot org

The bug is still here.

------------------------------------------------------------------------

[2007-02-24 09:03:50] stas at FreeBSD dot org

> The current code is fine, we should not hardcode buffer > sizes

if they cannot be retrieved, this could lead to > exploitable
situations. Also if the return buffer length of > 0 it probably
indicates a problem.

1) According to POSIX it's not a problem
2) Besides that one check is missing (take a look at patch), so you're
effectively trying to malloc (size_t)-1 bytes on FreeBSD currently,
which leads to crash.

------------------------------------------------------------------------

[2007-02-23 23:53:25] [email]iliaa@php.net[/email]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
[url]http://www.php.net/manual/[/url] and the instructions on how to report
a bug at [url]http://bugs.php.net/how-to-report.php[/url]

The current code is fine, we should not hardcode buffer sizes
if they cannot be retrieved, this could lead to exploitable
situations. Also if the return buffer length of 0 it probably
indicates a problem.

------------------------------------------------------------------------

[2007-02-23 14:07:38] [email]tony2001@php.net[/email]

Ilia, please take a look at this, IIRC you added those sysconf()
patches.

------------------------------------------------------------------------

[2007-02-23 13:55:02] [email]tony2001@php.net[/email]

>Yeah... According to susv3:

Yes, I know that, thanks.
But that does not mean "if (buflen < 1)" is incorrect.
I don't think that zero buflen is a correct value (and even if it is,
it's useless).

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[nlopess@php.net]

ID: 40600
Updated by: [email]nlopess@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Bogus
+Status: Assigned
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:

He is refering to this part of the patch:
@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;


so there is no check there for a negative return value.


Previous Comments:
------------------------------------------------------------------------

[2007-02-26 01:59:47] [email]iliaa@php.net[/email]

buflen check disallows values that are less then 1, so how
will you ever allocate a negative value?

RETURN_FALSE will terminate the function.

------------------------------------------------------------------------

[2007-02-25 23:04:42] stas at FreeBSD dot org

The bug is still here.

------------------------------------------------------------------------

[2007-02-24 09:03:50] stas at FreeBSD dot org

> The current code is fine, we should not hardcode buffer > sizes

if they cannot be retrieved, this could lead to > exploitable
situations. Also if the return buffer length of > 0 it probably
indicates a problem.

1) According to POSIX it's not a problem
2) Besides that one check is missing (take a look at patch), so you're
effectively trying to malloc (size_t)-1 bytes on FreeBSD currently,
which leads to crash.

------------------------------------------------------------------------

[2007-02-23 23:53:25] [email]iliaa@php.net[/email]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
[url]http://www.php.net/manual/[/url] and the instructions on how to report
a bug at [url]http://bugs.php.net/how-to-report.php[/url]

The current code is fine, we should not hardcode buffer sizes
if they cannot be retrieved, this could lead to exploitable
situations. Also if the return buffer length of 0 it probably
indicates a problem.

------------------------------------------------------------------------

[2007-02-23 14:07:38] [email]tony2001@php.net[/email]

Ilia, please take a look at this, IIRC you added those sysconf()
patches.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]

[tony2001@php.net]

ID: 40600
Updated by: [email]tony2001@php.net[/email]
Reported By: stas at FreeBSD dot org
-Status: Assigned
+Status: Bogus
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:

Nuno, this part of the patch has been applied 3 days ago.


Previous Comments:
------------------------------------------------------------------------

[2007-02-26 14:03:00] [email]nlopess@php.net[/email]

He is refering to this part of the patch:
@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R

grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;


so there is no check there for a negative return value.

------------------------------------------------------------------------

[2007-02-26 01:59:47] [email]iliaa@php.net[/email]

buflen check disallows values that are less then 1, so how
will you ever allocate a negative value?

RETURN_FALSE will terminate the function.

------------------------------------------------------------------------

[2007-02-25 23:04:42] stas at FreeBSD dot org

The bug is still here.

------------------------------------------------------------------------

[2007-02-24 09:03:50] stas at FreeBSD dot org

> The current code is fine, we should not hardcode buffer > sizes

if they cannot be retrieved, this could lead to > exploitable
situations. Also if the return buffer length of > 0 it probably
indicates a problem.

1) According to POSIX it's not a problem
2) Besides that one check is missing (take a look at patch), so you're
effectively trying to malloc (size_t)-1 bytes on FreeBSD currently,
which leads to crash.

------------------------------------------------------------------------

[2007-02-23 23:53:25] [email]iliaa@php.net[/email]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
[url]http://www.php.net/manual/[/url] and the instructions on how to report
a bug at [url]http://bugs.php.net/how-to-report.php[/url]

The current code is fine, we should not hardcode buffer sizes
if they cannot be retrieved, this could lead to exploitable
situations. Also if the return buffer length of 0 it probably
indicates a problem.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/40600[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=40600&edit=1[/url]