AmirWatad.com

Linux Fork Bomb Explained

One famous way to crash your Linux system is to run a “fork bomb” in the terminal. A variant of it looks like this:

WARNING: Malicious code. Don’t run it!

This code looks strange, but it’s actually a conventional code in Bash. To make it a little more obvious, let’s replace the : (colon) with the word bomb. So, our code now looks like this:

Arranging the code a little more will leave us with this:

Namely, the above code defines a bash function called bomb (colon in the original code), which calls itself recursively twice through a pipe, and sends the recursion call to the background. After the function is defined, all you need is to call it.
Now we just have a process which splits itself (a.k.a fork) forever, creating a huge number of processes which will utilize every single cycle of your CPU, causing the system to get stuck/reboot/crash.

Why to send the job to the background?

The answer is simple: If we run the recursive call in the foreground, the calling function will not complete until the call returns.
Since there is no stop condition for this recursion, the calling function would wait forever, which will allow killing it and all its children with [ctrl]+[C].
On the other hand, when running the recursive call in the background, the calling function will complete immediately, and it won’t be that easy to kill its child processes.
(It’s almost impossible to kill them even with the kill or killall commands, because the number of processes will grow exponentially and will utilize the whole CPU in a very short time, leaving you with the only option: To reboot).

Another question: Why calling twice?

In a “C-style” fork, after a process forks, it will continue to be alive, i.e., after a fork, we’ll have two processes: The parent, and the child.
But here in Bash, it’s not the same: Because we did the recursive call in the background, the calling process will “die” as soon as it makes the recursive call, so, if we call the function only once in the recursion, we’ll have always one process which will replace its parent, and this is not what we’re trying to achieve.

A C code with similar functionality to the above one is the following:

One way to protect your system from such fork bombs, is to limit the number of user processes in the system. An explanation of how to do this along with an explanation about the above fork bomb can be found here.

Another explanation about fork bombs, with examples in different languages can be found here.

Related posts:

1. Infinite zip File

Tags: Bash, Linux, Security