Bombe fork.

Une bombe fork est du code malveillant ou accidentel qui crée des processus enfants de manière récursive, doublant à chaque cycle jusqu'à saturer les limites du noyau, la mémoire ou le CPU et rendre le système inopérant. La ligne POSIX classique :(){ :|:& };: définit une fonction nommée : qui redirige deux copies d'elle-même en arrière-plan puis l'invoque ; chaque génération double le nombre de processus, si bien que la table des processus se remplit en quelques secondes. L'idée précède largement Unix — l'un de ses tout premiers noms est le programme « wabbit » ou lapin, signalé sur un mainframe Burroughs de l'Université de Washington vers 1969-1974.

Les bombes fork ne se propagent pas en réseau comme les vers ; ce sont des attaques locales d'épuisement de ressources, mais très efficaces sur des hôtes partagés multi-utilisateurs, des runners CI et des conteneurs, où un unique utilisateur non privilégié peut priver tout le monde de service.

Les défenses plafonnent les ressources qu'une arborescence de processus peut consommer plutôt que de bloquer l'appel système. Sous Linux, les contrôles clés sont ulimit -u / PAM pam_limits (nproc) pour borner les processus par utilisateur, et le contrôleur cgroups pids (pids.max) — que Docker et Kubernetes exposent via --pids-limit — pour plafonner le nombre de tâches d'un conteneur. L'isolation des comptes, les sandboxes pour code non fiable et les exécuteurs CI dédiés limitent davantage le rayon d'impact.

flowchart TD
  A["La fonction :()<br/>s'appelle deux fois"] --> B[Enfant 1]
  A --> C[Enfant 2]
  B --> D[Petit-enfant]
  B --> E[Petit-enfant]
  C --> F[Petit-enfant]
  C --> G[Petit-enfant]
  D --> H["... croissance exponentielle ..."]
  E --> H
  F --> H
  G --> H
  H --> I{"pids.max / ulimit -u<br/>atteint ?"}
  I -->|Aucune limite| J[Table des processus épuisée — l'hôte se fige]
  I -->|Limite définie| K[Les nouveaux forks échouent avec EAGAIN — l'hôte survit]