Bug 133069 - signal queuing DoS
signal queuing DoS
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Ingo Molnar
Brian Brock
: Security
Depends On:
Blocks: 133089
  Show dependency treegraph
Reported: 2004-09-21 10:33 EDT by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-02 14:15:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2004-09-21 10:33:53 EDT
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:

this issue was fixed in upstream here:
Comment 1 Alex Leonhardt 2004-10-25 10:41:43 EDT
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 !
Comment 2 Ernie Petrides 2004-10-25 16:42:41 EDT
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 04:27:03 EST
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-26 20:26:47 EST
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.

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 14:15:44 EDT
Closing as WONTFIX per Ingo's recommendation.

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