From: berny@tndsyd.oz.au (Berny Goodheart) Subject: (SUMMARY) was RE: How do you CRASH your UNIX System Date: 10 Apr 1991 23:57:16 +0000 A while ago I posted a request for information about how you can crash your version of UNIX. Some of you expressed your opinion that this idea of posting such information could be detrimental to the UNIX community. I believe that the UNIX community should be aware of these problems and there is no better place to explain them than on the net. Incidentally, for those of you that showed some concern that I work for TANDEM Computers Incorporated and that this is the reason for me collecting this information, I should like to point out that I placed this request to help me with my research for a new book which I am writing called "Fault Tolerant UNIX". This is a PRENTICE HALL project and has no connection with TANDEM Computers Incorporated. It was pointed out to me that if I would have explained this in the first place I would not have been flamed. I agree, so please accept my apologies. BTW: the book is NOT about Tandem's Integrity-S2. My thanks go out to all that replied and the following is a summary of those replies. Berny Goodheart (Asia/Pacific Technical Consultant for UNIX Systems). ###################################################################### We're running a number of ICL Unix boxes here. Two of them I was able to crash whenever I wanted; one of those has been fixed. Details: - ICL Clan 5 (recently known as DRS500) Actually a CCI Power 6/32 running a tahoe kernel, on top of which a System V.2 system has been built (e.g. it doesn't do ln -s, but symlink(2) is there for the taking). On this, 'stty line 2' causes a panic... (or any line discipline other than 1). - ICL Clan 4 (newer models known as DRS400) A 68020 system built by Datamedia, running a system V.2.0 kernel. On this, 'ld' by itself generates an empty a.out file. Running this caused a system halt (no message on console, system ready led extinguishes on the box, something that didn't even happen with 'halt'...) This has been fixed in later releases. This was quite bothersome (someone would want to type 'ls', made a typo and typed 'ld' instead; "Hmmm, no output... Try again.... 'ls'.... Hey, what's that a.out? Let's try... 'a.out'... CR ... CR... Hey, the system's hanging!!) ###################################################################### I was recently porting a device driver from Interactive 386ix to SCO Unix, and the calling conventions on the sptfree() function are somewhat different: On Interactive, a 1 as the last parameter means "don't sleep while freeing", while under SCO the 1 means "return the memory to the free page pool". Now, when you allocate memory to map to a physical device (rather than from the free pool), and then free it with a 1 under SCO, crashola! ###################################################################### 1. In SunOS 3.2 you could make the machine crash by passing an empty string as one of the arguments (don't remember which) to the link() system call. 2. In the old SysVr2-based OS for the NCR tower32/600 (don't remeber what NCR called it - sorry) you could do "stty line 1" (or some other number) and make the system crash. Obviously there was no bounds checking to ensure that the line discipline was one of the legal ones... (pointers to the line discipline routines for each line disc. are kept in an arry indexed by the line discipline number). This might be a generic SysVr2 (and below) bug. ###################################################################### Here is the promised CRASHME.C. It has been reported that the behavior of this program is highly dependant on system load, amount of system memory, etc. The results are not easily to reproduce in many cases. If you really want to give a system the acid test then create a shell script with thousands of different calls to crashme, and run multiple copies of these at the same time in different processes. BEWARE: Obviously, DO NOT RUN THIS on a MACHINE WHICH HAS OTHER USERS, or is a FILESERVER. #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh crashme.1 <<'END_OF_crashme.1' X.TH CRASHME 1C LOCAL X.SH NAME Xcrashme \- test operating environment software robustness X.SH SYNOPSIS X.B crashme X[NBYTES] [SRAND] [NRYTES] X.SH DESCRIPTION X.I crashme Xis a very simple program that tests the operating environment's Xrobustness by invoking random data as if it were a procedure. XThe standard signals are caught and handled with a setjmp back Xto a loop which will try again to produce a fault by executing Xrandom data. X X.RE X.SS COMMAND LINE OPTIONS X.TP 8 X.BI [NBYTES] XThe X.I [NBYTES] Xshould be an integer, specifying the size of the random data string Xin bytes. X.TP X.BI [SRAND] XThe X.I [SRAND] Xis an input seed to the random number generator, passed to srand. X.TP X.BI [NTRIES] XThe X.I [NTRIES] Xis how many times to loop before exiting normally from the program. X.SH FILES Xcrashme.c X.PD X.SH DIAGNOSTICS XWhen a signal is caught the number and nature of the signal is indicated. X.SH BUGS XNot all signals are caught, and the state of the user program/process Xenviroment can be sufficiently damaged such that the program terminates Xbefore going through all [NTRIES] operations. X XBeware: This program can crash your computer and possibly corrupt Xyour files if the operating system on it is buggy. X.SH AUTHOR XGeorge J Carrette. GJC\@BU-IT.BU.EDU END_OF_crashme.1 if test 1250 -ne `wc -c crashme.c <<'END_OF_crashme.c' X/* crashme: Create a string of random bytes and then jump to it. X crashme */ X Xchar *crashme_version = "1.1 19-SEP-1990"; X X/* X * COPYRIGHT (c) 1990 BY * X * GEORGE J. CARRETTE, CONCORD, MASSACHUSETTS. * X * ALL RIGHTS RESERVED * X XPermission to use, copy, modify, distribute and sell this software Xand its documentation for any purpose and without fee is hereby Xgranted, provided that the above copyright notice appear in all copies Xand that both that copyright notice and this permission notice appear Xin supporting documentation, and that the name of the author Xnot be used in advertising or publicity pertaining to distribution Xof the software without specific, written prior permission. X XTHE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING XALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL XHE BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR XANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, XWHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, XARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS XSOFTWARE. X XA signal handler is set up so that in most cases the machine exception Xgenerated by the illegal instructions, bad operands, etc in the procedure Xmade up of random data are caught; and another round of randomness may Xbe tried. Eventually a random instruction may corrupt the program or Xthe machine state in such a way that the program must halt. This is Xa test of the robustness of the hardware/software for instruction Xfault handling. X X Note: XSeen to be able to crash a SUN-4/110 OS 4.1, SUN-4/280 OS 4.0.3: X %crashme 1000 10 200 XAlso various combinations of inputs have been reported to crash Xother machines. X XComments may be addressed to the author at GJC@BU-IT.BU.EDU X XVersion Date Description X---------------------------------------------------------------------- X 1.0 early 1990 initial hack. X 1.1 19-SEP-1990 added more signals and an alarm to abort looping. X X*/ X X X#include X#include X#include X Xlong nbytes,nseed,ntrys; Xunsigned char *the_data; X Xjmp_buf again_buff; X Xvoid (*badboy)(); X Xvoid again_handler(sig, code, scp, addr) X int sig, code; X struct sigcontext *scp; X char *addr; X{char *ss; X switch(sig) X {case SIGILL: ss = " illegal instruction"; break; X case SIGTRAP: ss = " trace trap"; break; X case SIGFPE: ss = " arithmetic exception"; break; X case SIGBUS: ss = " bus error"; break; X case SIGSEGV: ss = " segmentation violation"; break; X case SIGIOT: ss = " IOT instruction"; break; X case SIGEMT: ss = " EMT instruction"; break; X case SIGALRM: ss = " alarm clock"; break; X default: ss = "";} X fprintf(stderr,"Got signal %d%s\n",sig,ss); X longjmp(again_buff,3);} X Xset_up_signals() X{signal(SIGILL,again_handler); X signal(SIGTRAP,again_handler); X signal(SIGFPE,again_handler); X signal(SIGBUS,again_handler); X signal(SIGSEGV,again_handler); X signal(SIGIOT,again_handler); X signal(SIGEMT,again_handler); X signal(SIGALRM,again_handler);} X Xcompute_badboy() X{long j,n; X n = (nbytes < 0) ? - nbytes : nbytes; X for(j=0;j> 7) & 0xFF; X if (nbytes < 0) X {fprintf(stdout,"Dump of %ld bytes of data\n",n); X for(j=0;j 0) X (*badboy)(); X else if (nbytes == 0) X while(1);} X Xmain(argc,argv) X int argc; char **argv; X{if (argc != 4) {fprintf(stderr,"crashme \n"); X exit(1);} X fprintf(stdout,"Crashme: (c) Copyright 1990 George J. Carrette\n"); X fprintf(stdout,"Version: %s\n",crashme_version); X nbytes = atol(argv[1]); X nseed = atol(argv[2]); X ntrys = atol(argv[3]); X fprintf(stdout,"crashem %ld %ld %ld\n",nbytes,nseed,ntrys); X fflush(stdout); X the_data = (unsigned char *) malloc((nbytes < 0) ? -nbytes : nbytes); X badboy = (void (*)()) the_data; X fprintf(stdout,"Badboy at %d. 0x%X\n",badboy,badboy); X srand(nseed); X badboy_loop();} X Xbadboy_loop() X{int i; X for(i=0;imakefile <<'END_OF_makefile' Xcrashme: crashme.o X cc -o crashme crashme.o Xcrashme.o: crashme.c X cc -c crashme.c END_OF_makefile if test 82 -ne `wc -c readme <<'END_OF_readme' XThe purpose of the crashme program is to cause instruction faults Xthat would otherwise be only rarely seen in the normal operation Xof a system (where "normal" includes conditions of user programs Xwith bugs in them, and to executable code corruption due to Xmemory, disk, and network problems). X XCaution: Don't even *think* about running this program on a Xsystem without a projected mode operating of some kind. X XFor more information see the comments in the code. X XNote: The use of srand and rand is unlikely to result in a very Xgood random mapping unto a machine instruction set. X XInfinite loops will be broken out of (presumably) by the ALARM Xsignal. 10 seconds are given for this. Adjust as needed. X XIdeally a shell script should be set up to run crashme again and Xagain for hours and hours with different input settings. X X-George Carrette. GJC@BU-IT.BU.EDU END_OF_readme if test 859 -ne `wc -c #include #define PADCOUNT 262143 #define STEP 200 /* Eat as much memory as the system allows and exit. */ main() { struct chunk { /* one megabyte */ struct chunk *next; long pad[PADCOUNT]; } *tmp, *head= NULL; int k, count= 0; for(;;) { /* Try to allocate another megabyte */ tmp= (struct chunk *) malloc(sizeof(*tmp)); if(tmp==NULL) break; /* Report megabyte count */ count++; printf("%d megabyte%s\n", count, (count>1 ? "s": "")); /* Link in a simple list */ tmp->next= head; head= tmp; /* Go and actually use the memory. */ /* NB: using only every STEP word to speed up. */ for(k= 0; kpad[k]= k; } } /* Be a good kid and free everything */ printf("Freeing %d megabyte%s\n", count, (count>1 ? "s" : "")); for (tmp= head; tmp!= NULL;) { head= tmp->next; free(tmp); tmp= head; } } ---------------------------------------------------------------------- Tried it on a DG AViiON (DGUX 4.20). Same thing. It's not an IBM invention! It's sysV!! Gasp! ###################################################################### Dennis Richies states a few in his paper "The Security of the UNIX system". Gives an interesting shell script which will bring some systems down. ###################################################################### My favorite on SunOS 4.0x is df /dev/*b (the swap partition) It did not crash but the computer hangs forever. ###################################################################### Well I managed to make SunOS 4.0.3 panic on a 4/260 by trying to rmdir a directory that didn't exist (its inode had been lost in a disk crash but the directory entry was still there). ###################################################################### Well, my system has been running continuously for 72 days, 56 minutes. I would guess it is not very easy to crash. But the voltage fluctuations which come with lightning storms in the summer will do it every time. ###################################################################### main() { fork (); main (); } This brought the system crashing to a halt, before they set up a quota for process. The system was a SysV 3.0, on 3B5. Also, running two copies of Franz Lisp simultaneously would cause the system to crash. This bug has since been fixed. ###################################################################### On a really old system, SPIX running on SM-90 from Telmat, a loop like while (malloc(10240)); crashes the system after a while (panic: out of swap). This system did not check swap overflow. But, fortunately I don't think such systems are used anymore. ###################################################################### Here's a little piece of code that tends to crash my HP9000/340 machine running hp-ux 7.0. All you have to do is add and extra & and the machine goes splat. main() { char hostname[100]; unsigned int size = 100; /* ** If you accidently put an & sign on ** size then the machine crashes ! ** ** eg. gethostname( hostname, &size); */ if ( gethostname( hostname, size) != 0 ) printf("gethostname() failed \n"); else printf("gethostname = %s\n", hostname); } ###################################################################### Should I or shouldn't I? Do you know, this is exactly the question a student here asked me a few months ago. He's now lost his account. Ah well, this is a rare (perhaps endangered) system, so... On a Sphere 325 under unix System V Release 2.2, I once attempted cat /dev/tty (similarly for other devices). I thought that if I did this, then I could find out whether any of these filenames was a synonym for a "micom" line out to the University, so that I could run kermit through it. Instead, the OS seized. My, was I worried. ###################################################################### main() { int fd; long now; time(&now); if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) return(1); while ( write(fd,&now,sizeof(long)) == sizeof(long) ) ; close(fd); return(0); } ###################################################################### In an older release of SunOS (3.4 I think), it was possible to crash the system by cat /etc/motd /dev/printer The machine would attempt to reboot but fail because of filesystem glitches (not serious). Any non empty file would do actually. Apparently they hadn't got Unix domain sockets right in that release. It was fixed by 4.0. ###################################################################### > time(&now); > if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) > return(1); > while ( write(fd,&now,sizeof(long)) == sizeof(long) ) > ; A couple of years ago in an extreme fit of boredom, on an unused ATT 3B2/400 running SysV 3.1, I did the following: hack# yes > /dev/kmem (where yes just writes a stream of "y\n" to stdout) Nothing happened. I let it run for a couple of minutes with no apparent effect. Perhaps the writes weren't moving the seek pointer in kmem, so it wasn't writing over anything interesting. I wasn't energetic enough to find out. All in all, it didn't help my boredom. :) ###################################################################### > >[Code to scribble on /dev/kmem--deleted] Sheeeeiiittt. Just `reading' from /dev/kmem can hose your system if you have write-only registers mapped into kernel address space. Try: ``cat /dev/kmem >/dev/null''. ###################################################################### Might I suggest a nicer way to abuse your Unix? This works even if there is a per-user process limit... #define BIGNUM 128*1024*1024 #define PAGESIZE 4*1024 char eatmem[BIGNUM]; main() { for (i=0 ; i += PAGESIZE ; i < BIGNUM) ++eatmem[i]; } Define BIGNUM to be a REAL large amount of memory that your system will allow you to have in your DATASIZE limit. Alternately, you could MALLOC the memory instead of making it static, subject to your MEMORYUSE limit. Define PAGESIZE to be the size of the memory page the swapper pages in on your system. Now comes the fun part: foo.bar% cc thrash.c foo.bar% a.out This cute little program will allocate a HUGE amount of memory, then read it in a way which makes the swapper do a page-in for *EVERY ACCESS*!! This slows the system down to a *TOTAL* crawl... Almost a crash. Of course you could write a program which simply malloc()s 512k, then another 512k, and another... (Assuming you do not have per-usre limits on 'memoryuse') Until you run out of swap space... PANIC: out of swap space Kids, *DO NOT TRY THIS AT HOME*!! Seriously, a cute little program can do *REAL* nasty things to your favourite UNIX box... Don't do in on any machine on which you plan on keeping your account :-) ###################################################################### This assembler yet-not-debugged student program crashed our Vax version of Ultrix 3.0. It made it on several computers with the same OS. Similar tests on BSD 4.3 and Ultrix4.0 just made the program core dump (which is natural). Generally it mis-uses register 12, same effect seems to be achieved by writing other sensitive registers ... I already asked the net about it but didn't get any replies. .data x: .long 91,-19,84 y: .long 53,-32,35 z: .long 32,54,60 .text .word 0 clrl r6 up: mull3 x(r6),y(r6),r7 # r7 <= x*y mull3 y(r6),z(r6),r8 # r8 <= y*z subl3 $1,z(r6),r9 # r9 <= z-1 mull3 x(r6),z(r6),r11 # r11 <= z*x addl3 r8,r7,r7 # r7 <= r7+r8 addl3 r9,x(r6),r9 # r9 <= r9+x # Oops! subl3 r9,r7,r12 # r12 <= r7-r9 # Oops! movl r12,r0 bsbw write movl x(r6),r0 bsbw write movl y(r6),r0 bsbw write movl z(r6),r0 bsbw write bsbw newline tstl r11 beql eql blss lss movl $1,r0 bsbw write jmp down eql: movl $0,r0 bsbw write jmp down lss: movl $-1,r0 bsbw write down: bsbw newline acbl $8,$4,r6,up chmk $1 ###################################################################### I really wish you hadnt posted this question. We have seen several possible answers to your question. One of which locked up the system. ###################################################################### My favourite way of rebooting a VAX running Ultrix V2.0-1 System #3: % mkdir foo % cd !$ % mkdir ../../foo % mv !$ .. ###################################################################### Someone talked about a 3 line script to crash a unix box here (but I can't find that message.) Anyway, what the script was: while (1) do mkdir 1; cd 1 end Minus some shell syntax. this is it. However, on newer OS's this won't work. I think it has a minfree on the inodes as well, or some thing like that. ###################################################################### A while back on the machine run by the CS Undergrad Assn. here at UC Berkeley there was a tongue-in-cheek "Space Warrior" competition to try to get people to clean up their disk space. One guy won by writing a little program which malloc'ed 1 meg of memory until the disk was 99% full. This works on Apollos because the swap is kept in a "first-class file", not in a separate partition. ###################################################################### AT&T 7300's and 3b1's (the Unix-PC) will crash if you write to the floppy from a shared-memory segment. AT&T 3b2's with the old 23Meg streaming tape will crash if you put the tape into streaming mode and then write a chunk larger than it expects in a single write(). (And since this magic size isn't mentioned in any of the normal documentation, it's pretty easy to miss...) ###################################################################### Awhile back, someone found that executing random data made quite a few RISC chips sieze up. ###################################################################### I recently downloaded some manpages for some utilities I have on the system. They were in the format that nroff -man makes readable (I'm not sure what you would call the format but). I mistakenly typed in: nroff -man sz (sz being the binary executable program in the same directory as the manpage listed below) instead of nroff -man sz.1 I got "floating point execption" twice on my screen, and the entire system crashed with a "PANIC: floating point execption" on the system console. The funny part is, I called NCR to complain and to this day they "have not been able to duplicate the problem". I have not tried it again, myself, but since I have changed a few O/S releases and some other stuff, I wonder if it would happen again. Oh yeah, the machine is an NCR Tower 32/800 running SYS V r2 (NCR# 01.03.01) unix based on AT&T unix (NCR has mucked around with stuff to get it to run on this multi-processor piece of junk). ###################################################################### I have even seen shell scripts to cause problems. I can just put $0 In a file by itself, make it executable and run it. It will continue to fork. Interrupt (^C for me) can kill this - eventually. Or if I put $0 & in a file then the system comes to a crawl. I can get out of this by moving or removing the script file. I could see someone doing this on accident trying to build a log file perhaps: $0 > logfile or for printing a message $0 Message >&2 either case forgetting to leave off the echo. ###################################################################### NeXT's ( NeXTae? NeXTi? ) seem to have an interesting aversion to FIFO's. I made a FIFO in my filespace that lives on a Sun 4, and tried to use the FIFO with my file space mounted on a NeXT. I'd forgotten that the FIFO existed, and hadn't put anything in it. When my newsposter tried to read from it, a nifty system panic window popped up, scrolled a bunch of friendly error messages and died. ###################################################################### .===========================================================================. | ACSnet: berny@tndsyd.oz UUCP: uunet!munnari.oz!tndsyd.oz.au!berny | | INTERNET: berny@tndsyd.oz.au DOMAIN: goodheart_berny@tandem.com | | PSMAIL: smtpgate @comm(berny@tndsyd.oz@munnari.oz.au) | TANDEM Computers Incorporated 76 Berry St, North Sydney, NSW, 2060, Australia ------- End of Forwarded Message