Description of problem:
The getXXXent functions blow up after recursing. Google reveals
numerous cases of people hit with "panic: realloc". WebMin blows up
on production systems (but not test systems!) because of this bug.
At end of data, glibc's getgrent_r returns ENOENT but does not set
errno. Arguably this is a bug in glibc:
However, PERL should be more resilient. The getXXXent functions
should clear errno before starting. (Note: this also handles the
recursion case as Perl_reentrant_retry calls them again after doubling
the buffer size.)
Version-Release number of selected component (if applicable):
Reproduced in perl-5.8.3-18 and perl-5.8.5-4.
(Was not present in perl-5.8.0-88.3.)
Steps to Reproduce:
1. Ensure that you have a group containing several hundred users in
/etc/group. The group and the users do not need to be "real". It's
thirty seconds work to create such a group in emacs. Our system blows
up unless we reduce the number of users below 360 - so if you create a
test case with 2^10 usernames you'll succeed.
2. Run the attached test program.
At the end of /etc/group, you get a panic: realloc.
At the end of /etc/group, glibc's getgrent_r returns ENOENT but errno
is unchanged. If there has previously been a recursion, errno
contains ERANGE. Perl_reentrant_retry sees the ERANGE and retries,
continuously doubling the buffer size until it explodes.
Created attachment 105806 [details]
Program to demo bug, assuming you have a long enough line in /etc/group
My assumptions about errno were the same as PERL's, and we're both
wrong. This is a PERL bug and not a glibc bug. See discussion at:
PERL must check the return value of getXXXent_r for ERANGE and ENOENT.
The value of errno is undefined after a getXXXent_r call - it may or
may not be clobbered by the implementation.
(Instead of checking for ENOENT, it's probably OK to test for 0 and
ERANGE, and then terminate the search on any other error.)
Now fixed with perl-5.8.5-18.FC3, to be released in FC-3 updates today
From User-Agent: XML-RPC
perl-5.8.5-18.FC3 has been pushed for FC3, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
assigning to email@example.com