Bug 143866 - CAN-2004-1237 kernel panic caused by auditd
CAN-2004-1237 kernel panic caused by auditd
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Charlie Bennett
Jay Turner
: Security
Depends On:
  Show dependency treegraph
Reported: 2004-12-30 08:04 EST by Josh Bressers
Modified: 2015-01-07 19:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-18 18:52:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:043 normal SHIPPED_LIVE Important: kernel security update 2005-01-18 00:00:00 EST

  None (edit)
Description Josh Bressers 2004-12-30 08:04:22 EST
Wade Holmes reported to secalert on 2004-12-28 a bug in auditd that
can cause a kernel panic.

An easily repeatable and exploitable problem with laus/auditd has been
discovered on RedHat Enterprise WS.  It has been tested on IA-32 and
x86_64, others running auditd may also be vulnerable.

To cause a kernel panic/oops execute the open() call under an
user/global execute only directory from cron.  Any user with access to
cron can initiate the panic.  Example:

User's crontab:
0 5 * * *       /tmp/folder/panic.pl

contents of panic.pl:
# this file does not have to exist.
$file = "/tmp/foo";

permissions of /tmp/folder:

If this is a kernel issue rather than a problem with auditd, please
refile this bug.

This issue does not seem to affect anything other than RHEL3.
Comment 4 Peter Martuccelli 2005-01-04 13:08:52 EST
This is already fixed in U5, marking entry as a duplicate of BZ #
141996.  The parent BZ # is 132245.

*** This bug has been marked as a duplicate of 141996 ***
Comment 5 Ernie Petrides 2005-01-04 16:01:05 EST
Josh, this can't be embargoed.  We've already made the fix in U5,
and although U5 has not yet been released, kernels with the fix
have already been given to key partners/customers for testing
other U5 fixes.
Comment 6 Josh Bressers 2005-01-04 16:04:49 EST
Ernie, That's fair.  I wanted to be sure.  Removing embargo.
Comment 7 Ernie Petrides 2005-01-12 22:53:44 EST
The fix for this problem has also been committed to the RHEL3 E5
patch pool this evening (in kernel version 2.4.21-27.0.2.EL).
Comment 8 David Lawrence 2005-01-18 18:52:36 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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