 | ||||||
| << Previous | INDEX | Search | src | Set bookmark | Go to bookmark | Next >> |
| ||||||
| |||||||||||||||||||||
X-RDate: Thu, 10 Jan 1980 10:45:39 +0500 (SSK) Date: Wed, 3 Dec 1997 22:36:03 +0000 (GMT) From: (Alan Cox) <alan@lxorguk.ukuu.org.uk> To: (Floody) <flood@evcom.net> Subject: [linux-security] Re: Insufficient allocations in net/unix/garbage.c Cc: linux-alert@redhat.com, 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
| |||||||||||||||||||||
|
|