perl-devel May 2006

perl-devel@lists.fedoraproject.org

6 participants
46 discussions

[Bug 191416] New: h2ph generates incorrect code for '#if defined A || defined B'
by Red Hat Bugzilla 04 Oct '06

04 Oct '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191416 Summary: h2ph generates incorrect code for '#if defined A || defined B' Product: Fedora Core Version: devel Platform: All URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39130 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai@redhat.com +++ This bug was initially created as a clone of Bug #191409 +++ Description of problem: This is perlbug #39130 - see URL . For cpp statements like : #if defined A || defined B h2ph would generate the code : if(defined (defined(&A) ? &A : 0) || defined (defined(&B) ? &B : 0)) { which is tautologous, as defined(0) is always true . This turns out to cause real problems on the Linux ppc64 platform, where "endian-ness" is selectable in the compiler; every inclusion of "endian.ph", which includes "bits/endian.ph", generates an error: $ perl -e 'require "sys/socket.ph";' Both BIG_ENDIAN and LITTLE_ENDIAN defined! at /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/bits/endian.ph line 10. Compilation failed in require at... Because h2ph generated this code in ../bits/endian.ph: if(defined (defined(&__BIG_ENDIAN__) ? &__BIG_ENDIAN__ : 0) || defined (defined(&_BIG_ENDIAN) ? &_BIG_ENDIAN : 0)) { if(defined (defined(&__LITTLE_ENDIAN__) ? &__LITTLE_ENDIAN__ : 0) || defined (defined(&_LITTLE_ENDIAN) ? &_LITTLE_ENDIAN : 0)) { die("Both\ BIG_ENDIAN\ and\ LITTLE_ENDIAN\ defined\!"); } For the cpp code in /usr/include/bits/endian.h: #if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN # if defined __LITTLE_ENDIAN__ || defined _LITTLE_ENDIAN # error Both BIG_ENDIAN and LITTLE_ENDIAN defined! ... The problem does not happen if the 'defined..' conditions are in parentheses - ie. #if defined(A) || defined(B) produces correct code: if( defined(&A) || defined(&B) ) A trivial fix for this is to simply replace the ': 0' with ': undef' in h2ph.PL line 517, as with this patch: --- perl-5.8.8/utils/h2ph.PL~ 2006-01-12 17:55:04.000000000 -0500 +++ perl-5.8.8/utils/h2ph.PL 2006-05-11 13:50:04.000000000 -0400 @@ -514,7 +514,7 @@ } } else { if ($inif && $new !~ /defined\s*\($/) { - $new .= '(defined(&' . $id . ') ? &' . $id . ' : 0)'; + $new .= '(defined(&' . $id . ') ? &' . $id . ' : undef)'; } elsif (/^\[/) { $new .= " \$$id"; } else { Version-Release number of selected component (if applicable): ALL How reproducible: 100% Steps to Reproduce: On a ppc64 platform with select-able endian-ness: # perl -e 'require "sys/socket.ph";' Actual results: Both BIG_ENDIAN and LITTLE_ENDIAN defined! at /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/bits/endian.ph line 10. Compilation failed in require at... Expected results: no error -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 5

[Bug 185406] New: h2ph problem with gcc internal defines
by Red Hat Bugzilla 04 Oct '06

04 Oct '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185406 Summary: h2ph problem with gcc internal defines Product: Red Hat Enterprise Linux Version: 4 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai@redhat.com +++ This bug was initially created as a clone of Bug #178343 +++ Description of problem: > Subject: h2ph problem > From: George Michaelson <ggm(a)apnic.net> > To: jvdias(a)redhat.com > Date: 2006-01-17 19:54 > > We just got bitten by 32bit vs 64bit logic in the .ph files generated > from socket.h/stddef.h/limits.h -bits/socket.ph to be exact. > > Undefined subroutine &main::__LONG_MAX__ called at (eval 436) line 1. > Compilation failed in require at > /usr/lib/perl5/5.8.5/i386-linux-thread-multi/sy s/socket.ph line 11. > Compilation failed in require at > /usr/lib/perl5/site_perl/5.8.5/i386-linux-threa d-multi/netinet/in.ph line > 9. > > > By removing some if/then/else logic, to make it just eval() the 32-bit > case, the problem went away. > > this was after applying an up2date on EL4 for perl 5.8.5: > > [ggm@curry log]$ uname -a > Linux curry.apnic.net 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT > 2005 i686 i686 i386 GNU/Linux [ggm@curry log]$ rpmquery -a | grep perl > newt-perl-1.08-7 > mod_perl-1.99_16-4 > perl-Net-DNS-0.48-1 > perl-Time-HiRes-1.55-3 > perl-5.8.5-24.RHEL4 > perl-Filter-1.30-6 > perl-URI-1.30-4 > perl-Digest-SHA1-2.07-5 > perl-Digest-HMAC-1.01-13 > [ggm@curry log]$ > > the RPM errata lists > > > * Tue Nov 01 2005 Jason Vas Dias <jvdias(a)redhat.com> - 3:5.8.5-17.RHEL4 > > - fix bug 170088: broken h2ph fixed with h2ph from 5.8.7 > > - fix bug 171111 / upstream bug 37535: IOCPARM_LEN should be _IOC_SIZE > > - fix bug 172236: make h2ph pick up gcc built-in include directory > > Is it possible you haven't tested enough of the outcomes here? Without > this, the perl just doesn't work. > > -George > > --- socket.ph.dist 2006-01-17 16:44:41.000000000 +1000 > +++ socket.ph 2006-01-17 16:44:49.000000000 +1000 > @@ -90,11 +90,7 @@ > eval 'sub SOL_IRDA () {266;}' unless defined(&SOL_IRDA); > eval 'sub SOMAXCONN () {128;}' unless defined(&SOMAXCONN); > require 'bits/sockaddr.ph'; > - if((defined(&ULONG_MAX) ? &ULONG_MAX : 0) > 0xffffffff) { > - eval 'sub __ss_aligntype () { &__uint64_t;}' unless > defined(&__ss_aligntype); - } else { > eval 'sub __ss_aligntype () { &__uint32_t;}' unless > defined(&__ss_aligntype); - } > eval 'sub _SS_SIZE () {128;}' unless defined(&_SS_SIZE); > eval 'sub _SS_PADSIZE () {( &_SS_SIZE - (2* $sizeof{ > &__ss_aligntype}));}' unless defined(&_SS_PADSIZE); eval("sub MSG_OOB () { > 0x01; }") unless defined(&MSG_OOB); Version-Release number of selected component (if applicable): ALL - including RHEL-4 perl-5.8.5-* not a problem with RHEL-3 perl-5.8.0, because gcc-3.2.3's limits.h #defines things like __LONG_MAX__ How reproducible: 100% Steps to Reproduce: $ perl -e 'require "sys/socket.ph";' Actual results: Undefined subroutine &main::__LONG_MAX__ called at (eval 256) line 1. Compilation failed in require at /usr/lib/perl5/5.8.6/i386-linux-thread-multi/sys/socket.ph line 11. Compilation failed in require at -e line 1. Expected results: no errors -- Additional comment from jvdias(a)redhat.com on 2006-01-19 12:20 EST -- Now that h2ph correctly picks up the gcc C standard includes, such as limits.h, from the gcc internal include directory (ie. /usr/lib/gcc/*.../include), which it was not doing before, due to bug 172236, some perl .ph files cannot be included because they refer to the newer gcc versions 'internal definitions' such as __INT_MAX__ / __LONG_MAX__ , which are no longer #define'd in any header file, but are 'built-in' to the newer gcc compilers, in the same way as __FILE__ or __LINE__ : $ echo 'int main(int argc, char **argv, char **envp) { long l=__LONG_MAX__; printf( "%ld\n",l); };' >tlm.c ( NOTE: no files are #include-ed ) $ gcc -o tlm tlm.c$ gcc -o tlm tlm.c tlm.c: In function ‘main’: tlm.c:1: warning: incompatible implicit declaration of built-in function ‘printf’ $ ./tlm 2147483647 gcc's C standard headers define constants such as LONG_MAX / INT_MAX in terms of these internal definitions: $ egrep 'define\ (INT|LONG)_MAX' limits.h #define INT_MAX __INT_MAX__ #define LONG_MAX __LONG_MAX__ During the generation of the perl platform h2ph includes, we should create a file included by limits.ph that includes definitions for all the gcc 'internal definitions' such as __LONG_MAX__ that might be referenced . -- Additional comment from jvdias(a)redhat.com on 2006-01-19 12:57 EST -- Created an attachment (id=123451) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123451&action=view) Program to produce perl header for C built-in definitions Something like the output of this program needs to be prepended to limits.ph during the build of the perl h2ph platform headers . -- Additional comment from rc040203(a)freenet.de on 2006-01-19 13:15 EST -- I must be missing something, but why do you try to extract GCC proprietary, internals? #include <limits.h> and printing the corresponding POSIX defines would be portable. C.f. http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html -- Additional comment from jvdias(a)redhat.com on 2006-01-19 15:54 EST -- RE: Comment #3: /usr/include/limits.h just #includes' gcc's limits.h, unless '__GNUC__ < 2', and gcc's limits.h would in any case be found first in by a '#include <limits.h>' . The whole issue of h2ph and perl's platform includes needs a major revamp, which it will get once perl-5.8.8 comes out (soon, I hope). -- Additional comment from jvdias(a)redhat.com on 2006-01-31 13:07 EST -- OK, it wasn't fixed in 5.8.8. I've now raised upstream perl bug #38385 : http://rt.perl.org/rt3/Ticket/Display.html?id=38385 on this issue, which includes a patch to fix it. This will be fixed in the next perl releases for RHEL-4, FC-4, and FC-5 (RHEL-3 is unaffected). -- Additional comment from jvdias(a)redhat.com on 2006-02-02 18:15 EST -- Created an attachment (id=124075) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124075&action=view) Program to include cpp internal built-in macros in system _h2ph_pre.ph -- Additional comment from jvdias(a)redhat.com on 2006-02-02 18:21 EST -- This problem is fixed with perl-5.8.8-1 in FC-5, with the patch sent upstream, which checks for the existence of cpp internal built-ins in Configure, and writes them to $Config{cppsymbols} so they are correctly written to _h2ph_pre.pl. This patch will be applied to subsequent perl releases for FC-4 and RHEL-4 , but this problem probably does not warrant a complete perl respin just to fix it. Meanwhile, simply run the 'patch_h2ph_pre.pl' script attached above, as root, and the system _h2ph_pre.ph (which gets included by every perl header file) will be patched to define cpp built-ins it does not already define . -- Additional comment from updates(a)fedora.redhat.com on 2006-03-13 17:12 EST -- >From User-Agent: XML-RPC perl-5.8.6-24 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 6

[Bug 178343] New: h2ph problem with gcc internal defines
by Red Hat Bugzilla 01 Oct '06

01 Oct '06

1 11

[Bug 188441] New: url(-relative=>1) is broken in CGI.pm
by Red Hat Bugzilla 01 Oct '06

01 Oct '06

1 13

[Bug 172739] New: Deep recursion in CGI::Carp::warn
by Red Hat Bugzilla 01 Oct '06

01 Oct '06

1 4

[Bug 185242] New: ioctl default minimum argument length of 256 should be restored
by Red Hat Bugzilla 21 Sep '06

21 Sep '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185242 Summary: ioctl default minimum argument length of 256 should be restored Product: Fedora Core Version: fc4 Platform: All URL: http://rt.perl.org/rt3/Ticket/Display.html?id=38223 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai@redhat.com +++ This bug was initially created as a clone of Bug #185240 +++ Description of problem: This is perl bug request ticket 38223 . Owing to the fix for bug 171111, where the length bitfield of the ioctl number argument, which specifies the length of the optional RD ioctl output third argument, was not being extracted correctly, and perl used 256 as the minimum length of the third argument in all cases, perl now does not ascribe any minimum length to the third argument unless the length bitfield is specified. This has the result that unless the length bitfield of the ioctl number is specified, a third argument of a buffer with insufficient length for the ioctl output will be overflowed, and perl will suffer a buffer overflow and a potential memory access violation or memory corruption, as generated by the following code (from perlbug RT# 38223): #!/usr/bin/perl require 'sys/ioctl.ph'; die "no TIOCGWINSZ " unless defined &TIOCGWINSZ; open(TTY, "+</dev/tty") or die "No tty: $!"; unless (ioctl(TTY, &TIOCGWINSZ, $winsize='')) { die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ; } ($row, $col, $xpixel, $ypixel) = unpack('S4', $winsize); print "(row,col) = ($row,$col)"; print " (xpixel,ypixel) = ($xpixel,$ypixel)" if $xpixel || $ypixel; print "\n"; Perl now correctly detects the buffer overflow: Possible memory corruption: ioctl overflowed 3rd argument at ./bug38223.pl line 5. This would not have occurred with perl versions before perl-5.8.6-18, because the length of all the ioctl third output arguments was made a minimum of 256 bytes. The overflow would not have occurred if the ioctl call had been : ioctl(TTY, &TIOCGWINSZ, $winsize='x'x16) or ioctl(TTY, &TIOCGWINSZ | (16 << &_IOC_SIZESHIFT), $winsize='') The default size of 256 has been restored in the latest upstream patch for this issue: ==== //depot/perl/perl.h#657 (text) ==== Index: perl/perl.h --- perl/perl.h.~1~ Fri Jan 13 04:10:49 2006 +++ perl/perl.h Fri Jan 13 04:10:49 2006 @@ -2977,8 +2977,8 @@ # define IOCPARM_LEN(x) (((x) >> 16) & \ # IOCPARM_MASK) # else # if defined(_IOC_SIZE) && defined(__GLIBC__) - /* on Linux systems we're safe */ -# define IOCPARM_LEN(x) _IOC_SIZE(x) + /* on Linux systems we're safe; except when we're not [perl #38223] */ +# define IOCPARM_LEN(x) (_IOC_SIZE(x) < 256 ? 256 : \ _IOC_SIZE(x)) # else /* otherwise guess at what's safe */ # define IOCPARM_LEN(x) 256 End of Patch. Version-Release number of selected component (if applicable): perl-5.8.6-22 How reproducible: 100% Steps to Reproduce: Invoke a READ ioctl with a 0 length bitfield and and output buffer third argument of insufficient length to hold the potential ioctl output. Actual results: Perl exits with error: Possible memory corruption: ioctl overflowed 3rd argument Expected results: Perl should enforce a minimum length of 256 bytes for the ioctl output buffer. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 6

[Bug 174684] New: Perl integer overflow issue
by Red Hat Bugzilla 21 Sep '06

21 Sep '06

1 15

[Bug 172336] New: getgrnam() crashes with "Out of memory" if /etc/group contains long lines
by Red Hat Bugzilla 21 Sep '06

21 Sep '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172336 Summary: getgrnam() crashes with "Out of memory" if /etc/group contains long lines Product: Fedora Core Version: fc4 Platform: i386 URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621 OS/Version: Linux Status: NEW Severity: security Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai@redhat.com +++ This bug was initially created as a clone of Bug #163958 +++ >From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Firefox/1.0.6 Description of problem: This bug has been fixed in Debian and in newest Perl. I'm just wondering does this concern RHEL 3 too, because we are rather close having "too much" users in one group and I would rather see this bug fixed before that we are going to have problems. * Fix test of reenterant function return values which was causing perl to malloc itself to death if ERANGE was encountered before ENOENT (such as a long line in /etc/group; closes: #227621). Version-Release number of selected component (if applicable): How reproducible: Didn't try Additional info: -- Additional comment from jvdias(a)redhat.com on 2005-11-02 16:23 EST -- This is PERL bug 37056, fixed with patch 25084 in bleadperl (5.9.x): ( http://rt.perl.org/rt3/Ticket/Display.html?id=37056 ) Subject: getgrent fails if a line in /etc/groups gets too long Date: Fri, 02 Sep 2005 15:53:08 +0200 To: perlbug(a)perl.org From: Michiel Blotwijk <michiel(a)blotwijk.com> This is a bug report for perl from michiel(a)altiplano.be, generated with the help of perlbug 1.35 running under perl v5.8.5. ----------------------------------------------------------------- [Please enter your report here] The function getgrent throws an error if a line in /etc/groups gets too long (> 3000 characters). This error can be reproduced as follows: 1/ Manually add a large number of users to a group in /etc/group. It doesn't really matter if these are real users or not, as long as the line exceeds 3000 characters. 2/ perl -e 'use User::grent; while (my $gr = getgrent() ) { print $gr->name."\n"; }' This will return an "Out of memory!" message. This thread seems to be related: http://lists.debian.org/debian-security/2005/06/msg00041.html Originally reported at Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621 As said in the Debian bug report: From: "Steinar H. Gunderson" <sgunderson(a)bigfoot.com> To: Peter Palúch <peterp(a)frix.fri.utc.sk> Cc: control(a)bugs.debian.org, 227621(a)bugs.debian.org, debian-security(a)lists.debian.org Subject: Re: perl: getgrnam() crashes with "Out of memory" if /etc/group contains long lines Date: Fri, 10 Jun 2005 15:03:02 +0200 It's about the same bug in perl as it was in glibc. reentr.pl line 698 reads: $call = qq[((PL_REENTRANT_RETINT = $call)$test ? $true : (((PL_REENTRANT_RETINT == ERANGE) || (errno == ERANGE)) ? ($seenm{$func}{$seenr{$func}})Perl_reentrant_retry("$func"$rv) : 0))]; The problem here is "errno == ERANGE". If, at any time, there's a line longer than the initial buffer, getgrent() (or any in the same family) will get ERANGE back (and errno will be set to ERANGE). However, this is never reset. Thus, when getgrent_r() hits EOF, it returns ENOENT, _but errno is still ERANGE_. Perl figures the buffer was too small, doubles it and tries again, but still gets ENOENT, of course (and errno is still ERANGE). This goes on forever and ever until you run out of memory (which happens quite fast). The solution is simply to remove "errno == ERANGE" AFAICS; getgrent_r() does not define what happens to errno, and the return message will always be ERANGE if the buffer is too small. I'm a bit tempted to tag this "security"; if a user can (say) change his or her own GECOS field to make it long enough, Perl programs using getpwent() will crash, for instance. I can't find any direct way to exploit it (chfn limits the length of the fields, for instance), but I'm still slightly concerned over the possibilities of a DoS; Cc-ing debian-security. /* Steinar */ I agree this bug has security implications . This problem affects all {get,set}* nss perl wrapper functions, not only getgrent . This problem affects all previous releases of PERL in all current Red Hat releases. The patch is very straightforward - replace all occurences of ((PL_REENTRANT_RETINT == ERANGE) || (errno == ERANGE)) with (PL_REENTRANT_RETINT == ERANGE) in reentr.inc and reentr.pl. This bug is now being fixed in these perl versions: Rawhide / FC-5 : perl-5.8.7-0.7.fc5 FC-4 : perl-5.8.6-16 RHEL-4 : perl-5.8.5-17.RHEL4 RHEL-3 : perl-5.8.0-90.2 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 3

[Bug 191387] New: RFE: support for perl-Spreadsheet-ParseExcel
by Red Hat Bugzilla 30 Aug '06

30 Aug '06

1 2

[Bug 190887] New: RFE: move perl-LDAP to Extras
by Red Hat Bugzilla 19 Jul '06

19 Jul '06

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel May 2006