Bug 174079 - [RHEL3] CVE-2005-3784 auto-reap DoS
[RHEL3] CVE-2005-3784 auto-reap DoS
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Staubach
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-11-24 05:55 EST by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

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

Attachments (Terms of Use)
Proposed patch (463 bytes, patch)
2005-12-16 14:33 EST, Peter Staubach
no flags Details | Diff

  None (edit)
Description Mark J. Cox (Product Security) 2005-11-24 05:55:52 EST
The issue below only affected 2.6 kernels, however the vulnerable code is part
of Enterprise Linux 3 due to the backport of nptl.  Therefore this issue may
also affect RHEL3.

+++ This bug was initially created as a clone of Bug #174078 +++

The auto-reap of child processes in Linux kernel 2.6 before
        2.6.15 includes processes with ptrace attached, which leads to
        a dangling ptrace reference and allows local users to cause a
        denial of service (crash).

Fixed upstream by
Comment 1 Peter Staubach 2005-12-16 14:33:47 EST
Created attachment 122345 [details]
Proposed patch
Comment 3 Ernie Petrides 2005-12-20 18:25:58 EST
Mark, would it be possible to dig up a reproducer for this?  There is
an extra check (tsk->state != TASK_STOPPED) in RHEL3 that is not in 2.6
that might preclude the vulnerability.  The patch in comment #1 carries
the risk of introducing a DoS regression (kernel memory exhaustion due
to not cleaning up task_struct's), so we need to be 100% confident that
we're fixing a real problem and that our fix is correct.

Thanks in advance.
Comment 6 Ernie Petrides 2005-12-21 16:12:01 EST
Thanks for the info, Mark.

The reproducer gets an error on the clone() syscall on RHEL3, because
the flags CLONE_THREAD and CLONE_DETACHED must either both be set or
both be clear.  So, I altered the test program to try both cases (both
flags set and both flags clear), and in neither case was there a problem
on my test system.

Further, the info in the thread in comment #4 indicates that the upstream
failure mode is that a BUG_ON() is hit in release_task(), and this does not
exist in RHEL3.  Rather, there is a test for the condition that prevents the
associated block of code from being executed in the problematic case.

The bottom line is that RHEL3 is not vulnerable to this bug.

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