Is it possible to cause a kernel panic with a single command line?

What would be the most straightforward such command for a sudoing user and what would it be for a regular user, if any?

Scenarios that suggest downloading something as a part of the command do not count.

  • 9
    :(){ :|:& };: maybe? – Carl Feb 26 '13 at 21:27
  • @carleeto Ok, could you explain that one to rest of us? – Chad Harrison Feb 26 '13 at 22:30
  • 13
    @hydroparadise It's called a "forkbomb". :() defines a function called : with the body of :|:&, meaning "run : and also run : in the background". ; ends the function definition, and : calls your new function, which endlessly spawns new versions of itself until you either hit process limits or the system grinds to a halt. It's a command that effectively freezes any system without good process limits set. Don't try this at home. – Phoshi Feb 26 '13 at 22:37
  • 1
    @Kevin You mean writing a C program, compiling it, and installing it as a driver, all in a single command line? A working example would be great. – Desmond Hume Feb 26 '13 at 23:13
  • 1
    A forkbomb does not necessarily causes a kernel panic. OTOH, one thing that may do that is to write (as root) is to, say, dd if=/dev/urandom of=/dev/mem (depending on your kernel version, you may not have /dev/kmem). But I wouldn't use the system after that. :) – rbrito Feb 27 '13 at 5:08
up vote 71 down vote accepted

FreeBSD:

sysctl debug.kdb.panic=1

Linux (more info here):

echo c > /proc/sysrq-trigger
  • 8
    echo c > /proc/sysrq-trigger sure does a good job in freezing a Linux system. But personally, an ol' good black screen of death narrating about a dramatic development of the call stack would feel like a more "canonical" kernel panic. – Desmond Hume Feb 27 '13 at 0:01
  • 2
    On Linux, you might have to echo 1 > /proc/sys/kernel/sysrq before you are able to echo c > /proc/sysrq-trigger. – Christian Mar 19 '14 at 8:16
  • how in OpenBSD? – mykhal Apr 24 '14 at 13:35
  • When one needs to prove how flawed an innocent piece of hw is, this might come in handy... – nemesisfixx Jul 18 '15 at 8:51
  • @mykhal See man.openbsd.org/ddb That will describe how to enter the kernel debugger on OpenBSD. – Kusalananda May 15 '17 at 8:14
mkdir /tmp/kpanic && cd /tmp/kpanic && printf '#include <linux/kernel.h>\n#include <linux/module.h>\nMODULE_LICENSE("GPL");static int8_t* message = "buffer overrun at 0x4ba4c73e73acce54";int init_module(void){panic(message);return 0;}' > kpanic.c && printf 'obj-m += kpanic.o\nall:\n\tmake -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules' > Makefile && make && insmod kpanic.ko

Compiles a module that crashes the kernel by calling the panic function, needs root, requires make and gcc

Replace the "buffer overrun at 0x4ba4c73e73acce54" in the command with something interesting for more drama.

  • 2
    This source code looks harmless enough. – Mark Lakata Feb 23 '16 at 21:34

The kernel is meant to keep running no matter what. So any way to cause a kernel panic by user interaction (other than deliberate vandalism by all-powerful root, like Bruce Ediger jokinkly proposes, and most kernels today are built so most of those pranks won't work in the first place) is an extremely serious bug, that would get fixed fast.

  • Well, there is no much use of the kernel when the system has been completely frozen by a non-sudoing user who issued a command in the likeness of :(){ :|:& };:. – Desmond Hume Feb 26 '13 at 23:27
  • 3
    @DesmondHume A good setup doesn't crash due to too many processes. Look in to the /etc/security/limits.conf file. – Vreality Feb 27 '13 at 1:43

compile the following code into a module and insmod it, sure you should get a panic:

static int crash_module_init(void)

{
     printf("crash module starting\n");
     int *p = 0;

     printk("%d\n", *p);

     return 0;
}

static void crash_module_exit(void)
{
    printf("crash module exiting\n");
}

module_init(crash_module_init);
module_exit(crash_module_exit);
  • 2
    This will cause an oops, but not a panic. – SkyDan Nov 7 '13 at 13:27

I don't know why this wasn't mentioned before...

sudo kill -9 1

Panics with the message "tried to kill init".

The easiest thing is to hold down alt + print screen (sysrq) and press c while still holding them It does the same as echo c > /proc/sysrq-trigger A little explanation: the sysrq key is used to send low-level commands to the kernel itself, as a last resort to try to save the system. If you hold alt + print screen(sysrq) down and press another key next to them, it does the same as if you were to echo the key in that sysrq-trigger file. They call it trigger for a reason ;3 The 'c' tells the kernel to crash (cause a kernel panic)

However, you may want to see the content of 'proc/sys/kernel/sysrq'. If it is 178 or anything else, you should change it to 1. 0 is all disabled, 1 is all enabled, and anything larger than 1 is a bitmap for the specific things the kernel allows to do with sysrq.

  • 1
    You can also slowly type "REISUB" While holding those magic keys down to restart your computer when it completely froze under linux. R-change keyboard mode to Xlate ||E-send SigTerm to all process|| I- send SigKill to all processes (except for init of course)||S- sync all mounted drives||U-Remount all devices in read-only||B- restarts instantly without any process killing or unmounting (which we took care about before). You can also use O instead of B to shut down instead of restart ;D have a nice time crashing your system – Yakusho May 7 at 6:59

Try this:

dd if=/dev/urandom of=/proc/sysrq-trigger 


This did a very fast kernel panic for me, but I'm not sure how safe the process is because I did it on the live Ubuntu installation. But the kernel did spam error messages at me when I did it in the pure terminal environment.

  • 1
    Why is it down voted? It addresses the question asked. – Josua Robson Nov 24 at 22:11

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.