Bug 133069

Summary:	signal queuing DoS
Product:	Red Hat Enterprise Linux 3	Reporter:	Josh Bressers <bressers>
Component:	kernel	Assignee:	Ingo Molnar <mingo>
Status:	CLOSED WONTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3.0	CC:	jbaron, mjc, peterm, petrides, redhat-bugzilla, riel, roland, tburke
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	impact=important,public=20040412
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-06-02 18:15:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	133089

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.