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
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
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. 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.
Closing as WONTFIX per Ingo's recommendation.