Mixter writes:
>
> The impact of the syslogd Denial Of Service vulnerability seems to
> be bigger than expected. I found that syslog could not be stopped from
> responding by one or a few connections, since it uses select() calls
> to synchronously manage the connections to /dev/log. I made an attempt
> with the attached test code, which makes about 2000 connects to syslog,
> using multiple processes, and my system instantly died with the message:
> 'Kernel panic: can't push onto full stack'
>
> I've been able to reproduce this as non-root user, although it had to
> be done two times to overcome the stronger user resource limits, but
> it worked. This has been tested with linux 2.0.38+syslog1.3 (redhat 5.2).
>
> As a temporary fix, I'd strongly advise everyone who hasn't to set proper
> user resource limits, but that is only a very temporary fix.
>
> Taking a guess, I would say that the panic is caused by instability of
> the linux select() implementation, and could therefore be abused in other
> programs that manage an unlimited amount of connections using the select
> syscall.
Why take a guess when it's so easy to grep the source?
% cd /usr/src/linux
% grep 'onto full stack' `find . -name '*.[ch]'`
./net/unix/garbage.c: panic("can't push onto full stack");
So it's nothing to do with select() and everything to do with Unix
domain socket garbage collection. The comments at the top of that
file say:
* 12/3/97 -- Flood
* Internal stack is only allocated one page. On systems with NR_FILE
* > 1024, this makes it quite easy for a user-space program to open
* a large number of AF_UNIX domain sockets, causing the garbage
* collection routines to run up against the wall (and panic).
* Changed the MAX_STACK to be associated to the system-wide open file
* maximum, and use vmalloc() instead of get_free_page() [as more than
* one page may be necessary]. As noted below, this should ideally be
* done with a linked list.
In other words, your file-max is too low and users on your system
could exhaust system-wide resources in other ways too. Echo a larger
number into /proc/sys/kernel/file-max, e.g.
echo 8192 > /proc/sys/kernel/file-max
(For those used to dealing with old BSD-ish kernels, this is similar
to panic() failure modes you get with maxusers is too low.)
If you can still reproduce the problem, I guess unix_gc() may need to
be fixed to use a more reliable upper bound for its stack size.
--Malcolm
--
Malcolm Beattie <mbeattieat_private>
Unix Systems Programmer
Oxford University Computing Services
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:13:47 PDT