Bug 137202 - getXXXent functions blow up after recursing
Summary: getXXXent functions blow up after recursing
Alias: None
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Robin Norwood
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-26 17:41 UTC by Mike Bird
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: 5.8.5-18.fc3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-17 19:38:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Program to demo bug, assuming you have a long enough line in /etc/group (390 bytes, text/plain)
2004-10-26 17:43 UTC, Mike Bird
no flags Details

Description Mike Bird 2004-10-26 17:41:25 UTC
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.)

How reproducible:


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.

Comment 1 Mike Bird 2004-10-26 17:43:18 UTC
Created attachment 105806 [details]
Program to demo bug, assuming you have a long enough line in /etc/group

Comment 2 Mike Bird 2004-10-26 20:57:30 UTC
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.)

Comment 3 Mike Bird 2004-10-26 23:06:22 UTC
Upstream notified:


Comment 4 Jason Vas Dias 2005-12-01 20:39:22 UTC
Now fixed with perl-5.8.5-18.FC3, to be released in FC-3 updates today

Comment 5 Fedora Update System 2005-12-01 23:55:47 UTC
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.

Comment 6 Matthew Miller 2006-07-10 21:00:43 UTC
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!

Comment 7 Robin Norwood 2006-10-01 23:32:09 UTC
assigning to rnorwood@redhat.com

Note You need to log in before you can comment on or make changes to this bug.