[1672] in linux-security and linux-alert archive
[linux-security] Re: Insufficient allocations in net/unix/garbage.c
daemon@ATHENA.MIT.EDU (Alan Cox)
Thu Dec 4 00:41:34 1997
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
To: flood@evcom.net (Floody)
Date: Wed, 3 Dec 1997 22:36:03 +0000 (GMT)
Cc: linux-alert@redhat.com, linux-security@redhat.com
In-Reply-To: <Pine.LNX.3.96.971203152036.1631B-100000@zothommog.evcom.net> from "Floody" at Dec 3, 97 03:47:35 pm
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
[Mod: linux-kernel and flood@evcom.net (Floody) removed from the To: list --
alex]
> program which opens up a large number of unix domain sockets, eventually
> causing a kernel panic in the garbage collection routines (which test for
> this limit and panic if hit); on systems which have NR_FILE (or
> /proc/sys/kernel/file-max) set to a value larger than 1024 or so. The
Yep. I know about this. The as shipped systems are all fine, if you up
it you need to change it. 2.1.x fixed this a while ago
> ! stack=(unix_socket **)kmalloc(max_stack * sizeof(unix_socket **),
> ! GFP_KERNEL);
This is not good. With a very large set of fd's you can now have the kmalloc
hang forever deadlocking the fd recovery. Use vmalloc and your idea is
correct.
(see 2.1.x)
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
