From: peter@zeus.DIALix.oz.au (Peter Wemm)
Newsgroups: comp.unix.sysv386
Subject: Re: perl 4.035 induces kernel panic in SVR4
Date: 13 Sep 1992 10:57:00 +0800
Organization: Karam Pty. Ltd., Perth, Western Australia.
NNTP-Posting-Host: zeus.dialix.oz.au

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
>In article <1992Sep10.204557.15522@husc3.harvard.edu>, maziere1@husc8.harvard.edu (David Mazieres) writes:
>|Thanks for all the help I've gotten.  In fact, my problem was simply that I
>|was including libucb before libc.  I changed the library flags to -lc -lucb,
>|and the new version tested fine. When I posted I figured I'd probably messed
>|up the flags somehow-the really disturbing thing is that a non-root user can
>|bring the whole system down.  I know the ucb library has tons of bugs in it,
>|but should even the most bizarely warped and misused system calls panic the
>|kernel?  (i.e. not should as in is this a good thing, but should as in have
>|other people been able to crash their SVR4 kernels reproducibly)

>  I used to crash Dell regularly with a temp sensitive motherboard ;-)
>Other than that I have never had a panic with Dell (or Intel, when I was
>doing beta on that). It's been totally resistant to software causing
>panics, one of the reasons I like it. I've never corrupted the
>filesystems, either, no that I think of it.

There is a program that is periodically posted called "crashme". It is
designed to do it's worst (or best) in an attempt to crash the kernel.
There have been *SERIOUS* side effects every time time I have run it, 
varying from instant panics, to trashing write protected files.

It sets up all signal handlers to point to some randomly generated trash
and then attempts to run the "garbage" as code. This induces a recursivly
called (and bombing) signal handler.   When the child finally died, the parent
noted the fact in a log file, and launched another one (or something like
that).

Some of the thinks I have seen.. (running as a "standard" user..)

* For a while, it would instantly panic the kernel. This changed after I
   reconfigured the kernel some time later for a new driver.
* Extreme performance degradation..
* core dumps (there shouldn't be any - the resource limit for core files
   was set to zero)
* core dumps to WRITE-PROTECTED core files!!!
* core dumps to WRITE-PROTECTED and ROOT-OWNED core files!!!
* even core dumps in write-protected (and even root owned (like /etc))
   directories!!!
* corrupted executable!!! - even when the executable is write protected and
   foreign owned...

This is what I mean....

Before:

dr-xr-xr-x   2 root     root         512 Mar 13 10:23 .
----------   1 root     root           0 Mar 13 10:22 core
---x--x--x   1 root     root       12560 Mar 13 10:23 crashme

After..

dr-xr-xr-x   2 root     root         512 Mar 13 10:26 .
----------   1 root     root         512 Mar 13 10:26 core
---x--x--x   1 root     root        4096 Mar 13 10:26 crashme

This is with "crashme" run as userid 103 (me).
If I start with no core file, one i created, just the same..
The executable is now corrupt... It resembles nothing like the original.

This was a fair while ago, but I still have the source that did this...
I saved a directory listing before I deleted them, rebooted and fsck'ed.. :-)

This is on Dell 2.1 BTW (I Think.. It might have been 2.0.1 back then.
I am not sure and I don't want to risk finding out...)

Imagine the consequences of typing this as a normal user...

cd /tmp (or somewhere on the root filesystem you can write to)
ln /etc/passwd core
crashme

Or how about
cd /tmp
ln /sbin/sh core
crashme

This was on a UFS root filesystem, and at the time a "pristine" kernel.
(No 387, and a 386-33, 16M ram, AHA-1542b)

-Peter

PS: The author of the program claimed that a suprising number systems he
tried never made it past an hour of "stress testing".
The known "bombable" cases listed in the source code include:
Most Suns, DecStation 3100,5000, IBM RT, RS/6000, Iris4d 3.3.2, and Nixdorf.
-- 
Peter Wemm : peter@zeus.dialix.oz.au   If it's broke, fix it (The MS-DOS way)
Work phone: +61-9-479-1855    If it aint broke, don't touch it (The Unix way)
Fax: +61-9-479-1134   If we can't fix it, it ain't broke (Maintainer's Motto)