[Bug 178343] New: h2ph problem with gcc internal defines
by Red Hat Bugzilla
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=178343
Summary: h2ph problem with gcc internal defines
Product: Fedora Core
Version: devel
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(a)redhat.com
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
--
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.
17 years, 6 months
[Bug 188441] New: url(-relative=>1) is broken in CGI.pm
by Red Hat Bugzilla
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=188441
Summary: url(-relative=>1) is broken in CGI.pm
Product: Fedora Core
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: bruno(a)wolff.to
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
url(-relative) no longer returns the original relative path before rewrites.
This used to work in FC4.
Version-Release number of selected component (if applicable):
perl-5.8.8-4
How reproducible:
100%
Steps to Reproduce:
1. Set up a redirect in your .htaccess file such as:
RewriteEngine On
RewriteBase /
RewriteRule ^testabc.cgi$ test.cgi
2. Create a test perl script, test.cgi such as:
#!/usr/bin/perl
use CGI qw/:standard -no_xhtml/;
print "Content-type: text/plain\n\n";
print url(-relative=>1), "\n";
print url(-absolute=>1), "\n";
3. Look at the web page /testabc.cgi
Actual results:
test.cgi
/testabc.cgi
Expected results:
testabc.cgi
/testabc.cgi
Additional info:
--
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.
17 years, 6 months
[Bug 172739] New: Deep recursion in CGI::Carp::warn
by Red Hat Bugzilla
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=172739
Summary: Deep recursion in CGI::Carp::warn
Product: Fedora Core
Version: fc4
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jorris(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
CGI::Carp::Warn experiences deep recursion when hit, followed by a segmentation
fault. This can make developing any web applications using CGI::Carp::Warn
difficult, as any trivial warning will cause pages of log output followed by a
crash.
See https://rt.perl.org/rt3/Ticket/Display.html?id=36521 for details and
possible patches.
Version-Release number of selected component (if applicable):
perl-5.8.6-15
How reproducible:
Always
Steps to Reproduce:
Execute script:
#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser);
use diagnostics;
warn "foo";
Results:
Deeply nested warning message followed by segfault.
--
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.
17 years, 6 months
[Bug 185242] New: ioctl default minimum argument length of 256 should be restored
by Red Hat Bugzilla
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(a)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.
17 years, 7 months
[Bug 174684] New: Perl integer overflow issue
by Red Hat Bugzilla
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=174684
Summary: Perl integer overflow issue
Product: Fedora Core
Version: fc4
Platform: All
OS/Version: Linux
Status: NEW
Severity: security
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: bressers(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Perl integer overflow issue
There exists an integer overflow problem in Perl which can lead to a
string format issue. If a large enough integer is supplied to a
printf statement which uses the %n conversion, it may be possible to
execute arbitrary code. This problem will not be easy to remotely
exploit as a very poorly written script will first be needed.
http://marc.theaimsgroup.com/?l=full-disclosure&m=113342788118630&w=2
Doesn't Affec: RHEL2.1
This issue also affects FC3
--
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.
17 years, 7 months
[Bug 172336] New: getgrnam() crashes with "Out of memory" if /etc/group contains long lines
by Red Hat Bugzilla
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(a)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.
17 years, 7 months
[Bug 184319] New: Spamassassin and SELinux
by Red Hat Bugzilla
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=184319
Summary: Spamassassin and SELinux
Product: Fedora Core
Version: fc4
Platform: i386
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: rsandu(a)softhome.net
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
Description of problem:
As described in SpamAssassin's man page, the program must create user_prefs in
$HOME/.spamassassin, where $HOME is the homedirectory of the user spamassassin
is run under.
When spamc is invoked from Postfix's master.cf file (as described at
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix) and SELinux is
enabled, Spamassassin can't create user_prefs file in /home/someuser, even if
"someuser" was created on purpose.
Version-Release number of selected component (if applicable):
spamassassin-3.0.4-2.fc4
selinux-policy-targeted-1.27.1-2.22
postfix-2.2.2-2
(stock Fedora Core 4 + updates March 06, 2006)
How reproducible:
Always.
Steps to Reproduce:
1. Invoke Spamassassin as a filter, from Postfix, as described in
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, with SELinux
enabled. Postfix users should be virtual users.
Actual results:
The process can't write user_prefs under /home/someuser.
Expected results:
A predefined system user should be created when installing Spamassassin (by the
rpm), with an appropiate, FHS-compliant homedirectory, in order to provide a
place to create user_prefs, when Postfix users are virtual users and SELinux is
enabled.
Spamassassin docs should indicate the correct way to proceed/configure in such
cases.
Additional info:
--
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.
17 years, 10 months
[Bug 178580] New: /etc/sysconfig/spamassasin is always modified
by Red Hat Bugzilla
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=178580
Summary: /etc/sysconfig/spamassasin is always modified
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: wtogami(a)redhat.com
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
QA discovered that /etc/sysconfig/spamassasin is being replaced during every
package intallation or upgrade.
# -a and --auto-whitelist options were removed from 3.0.0
# prevent service startup failure
perl -p -i -e 's/(["\s]-\w+)a/$1/ ; s/(["\s]-)a(\w+)/$1$2/ ; s/(["\s])-a\b/$1/'
/etc/sysconfig/spamassassin
perl -p -i -e 's/ --auto-whitelist//' /etc/sysconfig/spamassassin
Since FC3 spamassassin.spec %post contained this to remove user added options
during an upgrade from pre-3.0 SA that caused the new version to fail. QA
discovered that this perl syntax actually creates another file and deletes the
original file. This means that even if no change happens, the file has a
different timestamp and selinux security context.
Impact:
Not much, but it should be fixed some time in the future.
Fix:
This probably involves testing before doing the modification in order to avoid
an unnecessary replacement. In the replacement case chcon is needed in order to
maintain the correct selinux context.
--
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.
17 years, 10 months
[Bug 186531] New: perl-Mail-SPF-Query dependency missing
by Red Hat Bugzilla
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=186531
Summary: perl-Mail-SPF-Query dependency missing
Product: Fedora Core
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: lmacken(a)redhat.com
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
Description of problem:\
I am recieving the following error in /var/log/maillog:
Mar 23 21:22:04 tomservo spamd[23290]: Can't locate Mail/SPF/Query.pm in @INC
Version-Release number of selected component (if applicable):
spamassassin-3.1.0-5.fc5.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.
17 years, 11 months