Ya se lo he pasado a diversos amigos que utilizan linux como una gracia y todos los ordenadores petaron.

parece ser un error que ni siquiera ubuntu 7 se salva y lo peor del caso es no se necesita ser root desde mi terminal de Gnome escribi la secuencia y obtuve un resultado identico al descrito , pero mi pregunta es si es error del Kernel o ???.... aunque seria raro que un usuario escribiera eso no debe existir ese tipo de errores, esperemos se resuelva pronto...

Eso no es un fallo, es una simple funcion recursiva mal empleada, lo mismo da eso que

a(){ a|a& };a

o cualquier otra combinacion.

Sobre parchearla....no se puede parchear la estipidez humana, las funciones recursivas son necesarias, y si, mal empleadas caen en bucles infinitos.

Por no decir que como chorrada es mas viejo que maria castaña.

Para "parchearlo", hay que limitar el número de procesos que pueden ejecutar los usuarios, que por defecto son ilimitados. Con el módulo pam_limits se puede controlar sin problemas.

El bug es que el sistema permite que se coma todos los recursos, hice la prueba y se ha colgado instantáneamente, el sistema ha de repartir mejor los recursos entre los programas y los usuarios.

¿«caracteres liberados por uno de los programadores del kernel Unix»?
¿Alguien me explica qué pinta este post aquí? :-?

Cuánto tiempo tarda en actuar? Lo he probado en mi OS X y no lo tumba, de momento. La memoria libre se mantiene entre 30 y 35, sin bajar de 30 megas nunca. Aunque antes de poner el comando ya estaba así.

El fork bomb es una técnica vieja como el demonio. El problema no está en el kernel, sino en la configuración predeterminada del sistema (lo que comentaron arriba del número de procesos por usuario: "ulimit -u"), y me parece muy raro que no venga ya configurado por defecto a un valor aceptable. De hecho me parece un poco negligente.

Por ejemplo, en mi Gentoo lo puse a 8191, y resiste perfectamente este tipo de ataques, y en mi ArchLinux me acabo de fijar y está a 3071, pero no recuerdo haberlo configurado. En mi OpenBSD no lo configuré, pero está a 64, y parece perfectamente inmune al ataque. Ya lo probaré en Solaris 10 y NetBSD cuando pueda...