Intentional kernel panic under Linux?

Question

Is there any way to cause a kernel panic under Linux? I've heard of

echo c > /proc/sysrq-trigger

but it seems to just freeze, and I'm not sure it's a kernel panic. Is there any C program I can run as root to cause a kernel panic?

Solution 1

using kill

I think you could try the following:

$ kill -6 1

This sends signal # 6 to process #1 (the init process). If you read up in the signals man page: "man 7 signals":

   Signal     Value     Action   Comment
   -------------------------------------------------------------------------
   SIGHUP        1       Term    Hangup detected on controlling terminal
                                 or death of controlling process
   SIGINT        2       Term    Interrupt from keyboard
   SIGQUIT       3       Core    Quit from keyboard
   SIGILL        4       Core    Illegal Instruction
   SIGABRT       6       Core    Abort signal from abort(3)

You can find out how a process wants to handle the various signals (cat /proc/$PID/status). See this U&L Q&A for more info: How can I check what signals a process is listening to?.

overflowing memory

Another method is to overflow memory to induce a kernel panic. First you'll need to disable swap.

$ swapon -s
Filename                Type        Size    Used    Priority
/dev/mapper/VolGroup00-LogVol01         partition   14352376    3177812 -1

$ swapoff /dev/mapper/VolGroup00-LogVol01

Now to consume all the memory:

$ for r in /dev/ram*; do cat /dev/zero > $r; done

References

• How to force a Linux kernel panic
• How can I check what signals a process is listening to?

Solution 2

You can try sudo kill -SEGV 1. This will immediately crash init as if there were MM fault(kernel equivalent of segment violation).

Comments

[Michael Mrozek]

Why would you need this?

[tkbx]

@MichaelMrozek just to experiment. Although I imagine it could be useful to kernel developers.

[derobert]

You could load a kernel module which immediately tries to dereference NULL. That should give a fairly safe kernel panic. Or you could just have the module call panic. A kernel panic isn't just one, solitary thing—its a whole range of errors. You're asking something similar to "is there some way I can make a program crash?"

[jsbillings]

the sysrq method does create a kernel crash, but you probably don't have anything set up to handle the crashdump, and you aren't looking at the console where the crash information is sent.

[Lekensteyn]

@derobert Dereferencing NULL will give an Oops which only ends up being a panic if the kernel is configured as such (CONFIG_PANIC_ON_OOPS=y). To trigger a panic... simply load a module that calls panic()!

[Admin]

Kernel panic can also be achieved by using sh as init and then typing exit.

[syntaxerror]

@MichaelMrozek Oh, inducing this by force can be a great technique for people who use the kernel in embedded applications. Think of copy-protection mechanisms, respectively people using counterfeit / illegally modified hardware. The whole thinking behind to me seems very 80s, though: it reminds me of CBM Amiga times when they caused the "Guru" to blink if some copy protection was bypassed in erroneous (i. e. amateurish) ways ;)

[tkbx]

Weird. The first time, it seemed to "pause" xorg. My music stopped, and I saw the cli login you normally get when you change TTYs. I logged in and then switched back to tty7 (xorg), and the second time it did the same thing as echoing to /proc/sysrq-trigger. I guess you have to be in a tty to see the error information. And for the loop that consumes all memory, cat gets a write error saying the device is full, but the kernel must take care of it, becuase if I check my RAM, only ~300MB is used.

[Jander]

Actually, PID 1 is explicitly protected from signals it's not set up to catch. See unix.stackexchange.com/questions/7441

[slm]

@Jander - thanks. Is there a way to get a list of the signals that init is setup to catch?