Bug 133069 - signal queuing DoS
Summary: signal queuing DoS
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Ingo Molnar
QA Contact: Brian Brock
URL:
Whiteboard: impact=important,public=20040412
Depends On:
Blocks: 133089
TreeView+ depends on / blocked
 
Reported: 2004-09-21 14:33 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-02 18:15:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Josh Bressers 2004-09-21 14:33:53 UTC
It is possible for a user to exhaust the system process table by
causing a large number of threads/processes to be left in a zombie state.

More information is available here:
http://www.securityfocus.com/bid/10096/discussion/
http://www.securityfocus.com/archive/1/360123

this issue was fixed in upstream here:
http://linux.bkbits.net:8080/linux-2.6/cset@40d302b8vu5PRC3hBFweTrD2FKaAkw

Comment 1 Alex Leonhardt 2004-10-25 14:41:43 UTC
Hello, is this BUG already solved or is there a Kernel-Update from RH 
to be applied ? It seems a customer has exact this kind of DoS with 
some remote X workstations.

Kernel : 2.4.21-4.ELsmp
RH Enterprise Server
UNAME : Linux linux1 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 
2003 i686 i686 i386 GNU/Linux

Thank's a lot !
Alex


Comment 2 Ernie Petrides 2004-10-25 20:42:41 UTC
Alex, as far as I know, no fix for this has been committed to
any RHEL3 update.  Ingo, care to comment on this one?


Comment 4 Ingo Molnar 2005-01-26 09:27:03 UTC
this "signal issue" is in fact not the one fixed by the upstream
commit linked to - that points to a message-queue fix. I've Cc:-ed
Roland - do we have the signal DoS fix in taroon?

Comment 5 Roland McGrath 2005-01-27 01:26:47 UTC
The right bk link is this one.  Unfortunately this was done as several little
changesets relying on each other rather than a single one that does it all, so
there are a few other patches around the same time that are needed as well.
http://linus.bkbits.net:8080/linux-2.5/user=chrisw/cset@40d3096a-SL1w6-WXXD-LcW4G9pg1A?nav=!-|index.html|stats|!+|index.html|ChangeSet@-9M

I think we do indeed have this vulnerability in RHEL3.  We have the old code
there, which has a system-wide limit on the number of queued signals.
Anyone can consume this limit sending themself signals, and change behavior for
other signal-using processes on the system.

The 2.6 fix included adding a user-accessible RLIMIT_SIGPENDING limit that can
be set like RLIMIT_NPROC.  We cannot backport that aspect without changing
task_struct and breaking kABI, though it should be fine to instead have a
system-wide value (constant or sysctl) for the per-user limit.  A direct
backport of the underlying support changes struct sigqueue and user_struct,
so that also breaks kABI.  There may be some unused padding space inside struct
sigqueue we can steal for kludging around changing kABI for it.  If need be to
implement this without kABI changes, we can avoid changing user_struct by using
an additional uid hash table for the new information (sigpending count), ugly as
that is.

Comment 8 Ernie Petrides 2005-06-02 18:15:44 UTC
Closing as WONTFIX per Ingo's recommendation.


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