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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137199 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.) How reproducible: Always. 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. Actual results: At the end of /etc/group, you get a panic: realloc. Expected results: No panic. Additional info: 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137199 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.)
Upstream notified: http://guest:guest@rt.perl.org/rt3/Ticket/Display.html?id=32154
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. Thank you!
assigning to rnorwood