Code Golf of Death

Question

Write some code that causes a BSOD or kernel panic!

Rules:

• On Windows, you must cause a BugCheck (Blue Screen of Death), on Linux (or other *nix systems) you must cause a kernel panic.
• Must not damage the system (i.e. it should work on reboot)
• Kernel-mode drivers are allowed.
• State your OS and version information.
• Explain how the crash is caused.
• It's not against the rules to use tools that are specifically designed to cause a crash, but doing so isn't very creative!
• Highest upvotes wins.

Answer 1

Bash, x86 Linux 2.6.20 kernel

Warning: the following command may cause permanent damage to your system.

cat /dev/urandom > /dev/mem

Will output the following (try here). After this, the script hangs.

/var/root # cat /dev/urandom > /dev/mem                                        
BUG: unable to handle kernel paging request at virtual address 474e82a5         
 printing eip:                                                                  
c01450c4                                                                        
*pde = 00000000                                                                 
Oops: 0000 [#1]                                                                 
CPU:    0                                                                       
EIP:    0060:[<c01450c4>]    Not tainted VLI                                    
EFLAGS: 00000082   (2.6.20 #12)                                                 
EIP is at free_block+0x54/0xf0                                                  
eax: 00000000   ebx: 474e82a1   ecx: c00745c8   edx: c0005e80                   
esi: c0070ce0   edi: c002c1a0   ebp: 00000000   esp: c0085eec                   
ds: 007b   es: 007b   ss: 0068                                                  
Process events/0 (pid: 3, ti=c0084000 task=c0094030 task.ti=c0084000)           
Stack: c0076410 00000002 c0051db0 c0051db0 c0051da0 00000002 c002c1a0 c01457dd  
       00000000 c0070ce0 c002c1a0 c0091840 c0145800 c0145870 00000000 00000000  
       c02cb2a0 c02cb2a0 00000296 c011dd27 c003fab0 c0094030 c009413c 00047e6c  
Call Trace:                                                                     
 [<c01457dd>] drain_array+0x7d/0xa0                                             
 [<c0145800>] cache_reap+0x0/0x110                                              
 [<c0145870>] cache_reap+0x70/0x110                                             
 [<c011dd27>] run_workqueue+0x67/0x130                                          
 [<c011df17>] worker_thread+0x127/0x140                                                                
 [<c010c7d0>] default_wake_function+0x0/0x10                                    
 [<c010c817>] __wake_up_common+0x37/0x70                                        
 [<c010c7d0>] default_wake_function+0x0/0x10                                    
 [<c011ddf0>] worker_thread+0x0/0x140                                           
 [<c0120d94>] kthread+0x94/0xc0                                                 
 [<c0120d00>] kthread+0x0/0xc0                                                  
 [<c0102ee7>] kernel_thread_helper+0x7/0x10                                     
 =======================                                                        
Code: 04 0f 8d 8f 00 00 00 8b 44 24 08 8b 0c a8 8d 91 00 00 00 40 c1 ea 0c c1 e2

Here is another exception found with the same command:

/dev # cat urandom > mem                                                        
------------[ cut here ]------------                                            
Kernel BUG at c014514c [verbose debug info unavailable]                         
invalid opcode: 0000 [#1]                                                       
CPU:    0                                                                       
EIP:    0060:[<c014514c>]    Not tainted VLI                                    
EFLAGS: 00000046   (2.6.20 #12)                                                 
EIP is at free_block+0xdc/0xf0                                                  
eax: 1608347b   ebx: c009b010   ecx: c003f508   edx: c00057e0                   
esi: c009b000   edi: c002cd40   ebp: 00000000   esp: c0085eec                   
ds: 007b   es: 007b   ss: 0068                                                  
Process events/0 (pid: 3, ti=c0084000 task=c0094030 task.ti=c0084000)           
Stack: c009b010 00000004 c009b010 c009b010 c009b000 00000004 c002cd40 c01457dd  
       00000000 c02ddf20 c002cd40 c0091840 c0145800 c0145870 00000000 00000000  
       c02cb2a0 c02cb2a0 00000296 c011dd27 c005c5a0 c0094030 c009413c 000409ed  

Answer 2

C, 16 chars, for P5 x86

main=-926478352;

Remember the F00F bug everyone? I helped lock up a machine or two back in the day with this little program. (Yes, I've been golfing for that long.)

Granted, it's not quite what was asked for, and it only works on old steppings of the P5 Pentium chips. But in its favor, it's cross-platform, working on both Linux and Windows!

Answer 3

QBASIC, 38 Characters

DEF SEG=0:FOR I=0 TO 4^8:POKE I,1:NEXT

Not sure how you would define a BSOD or Kernel panic in DOS, but this is probably pretty close. When run the screen just goes blank, and the machine responds to nothing, not even Ctrl+Alt+Delete. You have to restart with a hard reset or power cycle to get the machine going again. This is running on DOS 6.22 under VirtualBox. Not sure exactly why it causes the system to crash, but, basically the program is writing (POKE) to memory that it has no business writing to.

Answer 4

sh (in JSLinux)

Linux gives the init process special protection against signals. However, I noticed that in JSLinux, /sbin/init is a shell script that executes other binaries (most symlinked to /bin/busybox).

This "infinite" while loop restarts sh as necessary:

while /bin/true; do

  setsid sh -c 'exec sh </dev/ttyS0 >/dev/ttyS0 2>&1'

done

However, what if /bin/true does not always return an exit code of 0? /bin is on the read-only root file system, yet Linux lets us change that using "bind" mounts:

cp -R /bin /tmp/boom
rm /tmp/boom/true
printf '#!/bin/sh\nexec [ $PPID != 1 ]' > /tmp/boom/true
chmod 755 /tmp/boom/true
mount -o bind /tmp/boom /bin
killall -9 sh

And we get:

/var/root # ./boom.sh
Killed
Kernel panic - not syncing: Attempted to kill init!

Answer 5

GTB, 13 characters

Executed from a TI-84 calculator

:"+"→_[_+_→_]

If most of the RAM is free, it will crash with ERR:MEMORY

Otherwise, the calculator's RAM is so clogged that it turns off and clears it besides.

Great example of a "calculator virus"

Answer 6

Batch (Windows 98)

\con\con

This is actually a BSOD Easter Egg of Windows 98...

Answer 7

Bash on Linux, 27 chars

echo c>/proc/sysrq-trigger

Or if you have sudo permissions:

echo c|sudo tee /proc/sysrq-trigger

Answer 8

get-process | stop-process -force

in powershell

Answer 9

:(){ :|:& };:

In bash shell,

I am not so sure if this counts here, but if you let it run long enough CPU overheats and system crashes, and it does reboots safely without harm, of course if you do it all the time there will be some system damage.

Answer 10

Ruby (run as root), 36 or 40 chars (depending on matches for /p*/s*r)

See http://www.kernel.org/doc/Documentation/sysrq.txt and search for 'c' (including quotes!) to see why it works.

open(Dir['/p*/s*r'][0],?a){|f|f<<?c}

EDIT: Longer version that works if you have other things matching /p*/s*r

open('/proc/sysrq-trigger',?a){|f|f<<?c}

EDIT 2: Intentionally overkill.

Answer 11

Linux bash

cat /dev/zero > /dev/mem

Clear the entire memory and cause a infinite kernel panic.

Try it here.

Answer 12

Batch, 15 bytes

:A
start
goto A

Merely overflows the memory in linear time by starting up cmd.exe hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds and hundreds of times.

There's a deadlier (but probably non-competing) 24-byte program that starts up itself over and over again, thus overflowing the memory in logarithmic time (i.e upgrading your RAM doesn't delay the crash). Suppose the below code is located in C:\a.bat:

:A
start C:\a.bat
goto A

.

Honestly I'm afraid to try those out.