Re: A long overdue fork-bomb defense ?

From: Robert Hailey
Date: Sat Apr 09 2011 - 18:26:07 EST

On 2011/04/09 (Apr), at 3:12 PM, Valdis.Kletnieks@xxxxxx wrote:

On Fri, 08 Apr 2011 15:47:13 CDT, Robert Hailey said:

log("fork_count generation");

This will involve painful locking on large systems with lots of procs running.

This logic (and the related painful locks) would be triggered only once in a small fractional proportion to the number of forks of the single greatest forker. But it is a solid observation, that if such a patch was in place there would be an overhead to it's use; I imagine it would take a considerable amount of time for a long running system to wrap it's fork counts.

Is there a better way to handle the integer overflows?

for ( p : process_table) {


Thankfully, this logic would only be triggered when the process table is full. At that point I doubt anyone would miss the compute time of even the most painful lock :)

if (fork_alert_level) {
if (fork_count >= fork_alert_level) {
signal(KILL, proc) && log('killed ...');
//don't: fork_alert_time=now();
if (now()-fork_alert_time>10 seconds?) {
fork_alert_level=0; //Relax

A smart attacker can probably use this to game the fork rate to fly just under
the wire, while still piling up lots of processes, *and* adding extra overhead
as it goes. If the rate limit is 5000 forks every 10 seconds, it can do 4500
every 10 seconds, and in a few minutes the poor scaling sections will eat your
system alive.

Perhaps there is a misunderstanding.... Although this logic is *sensitive* to forking rate, this is not directly acting on (or measuring) a forking rate. It is simply providing a metric by which processes can be compared (number of forks in self and ancestors), and providing something to do if we find that we are out of process table space (the limited resource in question). Of course... if the memory ceiling is reached first (fork/malloc), then that is a concern of the OOM-killer (a separate but related discussion).

Presuming for a moment that it works, I think the worst case is actually a single (perhaps compromised) process spawning child fork bombs. For that matter it could be a bash shell with the user setting them off. In that case it might *never* cause enough forking it to get itself automatically killed, but the system would still be [somewhat?] responsive through the attack b/c it no longer denies a legitimate fork, i.e. logging in & using a shell work, even while the process table is *FULL* of active fork bombs.

Even if a fork bomb is downgraded from "fatal" to "makes things darn slow", it's worth considering, no?

Robert Hailey

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at