How I accidentally ran a fork bomb and crashed my laptop

⚠️ Warning: Do not execute the code shown in this post. It will make your system unresponsive.

I wanted to observe linux kernel behavior under heavy load. My goal was to stress the CPU and observe scheduler behavior and per-process scheduling.

So I asked ChatGPT for a shell script, that will apply "some" on the CPU.

Unfortunately, I had no idea what a fork bomb was.

Here's the script that I ran...
⚠️ Warning: do not execute. bad idea. terrible idea

forkbomb() { 
  forkbomb | forkbomb & 
}; 
forkbomb

Yes. That is a fork bomb.

Observations:

The first time i ran the script, i saw fork() being called a couple of times in the terminal. So, I pressed Ctrl + Ca couple of times, and assumed it to have stopped.. It hadn't.

I closed the terminal and switched back to firefox -- where I immediately got an error message:
"A web page is slowing down your browser. What would you like to do? -- Stop It or Wait"
I clicked "Wait" thinking it was a browser glitch.

Believing I had mistyped the command, I executed the script again 🗿🗿

At that point my system had completely crashed. No amout of ctrl+alt+del or esc or function keys would fix it..
The entire machine was frozen.

I had no choice but to force power it off.

Post-Mortem: Digging into journalctl

After rebooting, I wanted to understand what exactly went wrong. I inspected system logs using journalctl.

The first major red flag:

Jan 24 23:20:00 laptop gnome-shell[3515]: libinput error: event5 - ELAN0712:00 04F3:30FD Touchpad: client bug: event processing lagging behind by 91ms, your system is too slow

This indicates that the GNOME Shell was unable to process inputs real time, i.e. the CPU schedler was lagging behing by 91ms! It was completely overwhemed.

Later Inputs showed kernel PCIe containtment events.
(The PCIe (Peripheral Component Interconnect Express) is responsible for managing the connecting link between the CPU and the peripherals. The PCIe in my case didn't fail, but panicked because it couldn't talk to the overwhelmed CPU.)

Jan 24 23:21:24 laptop kernel: pcieport 10000:e0:1d.0: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+

And repeated tracker filesystem miner warnings:
(a tracker is a background file indexing and search network. The tracker couldn't open a new file handle because the forkbomb had stolen them all. The system had reached Open File Limit)

Jan 24 23:08:33 laptop tracker-miner-fs-3[22996]: (tracker-extract-3:22996): GLib-GIO-WARNING **: 23:08:33.174: Error creating IO channel for /proc/self/mountinfo: Invalid argument (g-io-error-quark, 13)

None of these were root causes — they were secondary symptoms of massive resource starvation.

The real cause was the fork bomb

It should be mentioned that whenever I looked up on these errors individually, nothing actually seemed to be wrong with the system. They didn't seem very significant.

And this is the elegance of a fork bomb.

What a Fork Bomb Actually Is

A fork bomb is a tiny shell function that recursively spawns copies of itself, rapidly consuming:

  • Process table entries
  • CPU time
  • Memory
  • Scheduler runqueue slots
  • File descriptors

Classic form:

:(){ :|:& };:

Explanation:

  • : defines a function named :
  • :|: calls itself twice using a pipe
  • & backgrounds the process
  • : executes the function

This leads to exponential process creation.

We can observe this through my command history that Ilooked through after booting the system.

!../images/Pasted image 20260125004046.png
This script had executed over 2000 times in a span of seconds, saturating the kernel scheduler and effectively performing a local denial-of-service attack against my own system.

A simple yet elegant function, that is powerful enough to crash entire systems, that's what a forkbomb is.

A forkbomb is given it's name since the tiny script rapidly consumes all system resources through the fork systemcall.

Why My System Froze Completely

Once enough processes are created:

  • The kernel cannot schedule tasks fairly.
  • GNOME Shell cannot get CPU time.
  • Input events start lagging.
  • The UI freezes.
  • Even signal handling (Ctrl+C) becomes unreliable.

Eventually, the machine becomes fully unresponsive.

This is classic fork bomb behavior.

Lessons Learned

  • Never execute shell scripts directly from the internet or AI without understanding them.
  • Never perform kernel or scheduler stress testing on your host system.
  • Always use a VM, container, or cgroup sandbox for experiments like this.

Comments

Post a Comment