Red Hat Bugzilla – Bug 133069
signal queuing DoS
Last modified: 2007-11-30 17:07:04 EST
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:
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, as far as I know, no fix for this has been committed to
any RHEL3 update. Ingo, care to comment on this one?
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?
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
Closing as WONTFIX per Ingo's recommendation.