DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60MA6Bo02045290
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 60MA6Bo02045290
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=bWELLqEg
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E3154BC8979
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1769076370;
	bh=Vi6MJllBSjKjsbwDOVfEga6s/5lWtKb2vpUK5DFEoSA=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=bWELLqEgMKe0nSppxt6LvqqXf1HhWBaxce2c6CUoG+shB+UlPvnN3Gf1ilxH9WZFU
	 jus66mQZu5rZgVtUhAEhnQS9TjMFV4wHSfoeeMC5za2LWc5Zl7d8/7KaLjteXFCLwL
	 b4sdw0IVz6AiJ78kLQCGj3gGodNyRpQk+l6TF+lw=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D9B34BA2E2E
Date: Thu, 22 Jan 2026 11:05:20 +0100
To: cygwin AT cygwin DOT com
Subject: Re: Fork bomb question about Cygwin
Message-ID: <aXH2YPIcgWqd8zyX@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <MN2PR09MB492382DA1F993B72742E1A98A596A AT MN2PR09MB4923 DOT namprd09 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <MN2PR09MB492382DA1F993B72742E1A98A596A@MN2PR09MB4923.namprd09.prod.outlook.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Jan 21 20:37, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Hello All,
> 
> I apologize in advance if my question is off-topic for this mailing
> list, and if so, y'all are free to just ignore it.
> 
> In essence, I was under a (seemingly wrong) impression that user-level
> classic fork-bomb such as the infamous,
> 
> ":(){ :|:& };:"
> 
> would not be possible because Windows would run out of memory creating
> the processes, and at some point Cygwin's fork() would fail, thus,
> stopping the chain reaction.
> 
> That obviously is not the case, and the above (run by a non-privileged
> user) kills the OS quite successfully, rendering it totally
> non-responsive (even mouse stops moving at some point as well) with
> only a hardware reset being able to bring it back to life.
> 
> (To confirm, I experimented with that on the all current Windows 10
> Pro.)
> 
> So the first part of my question is, whether this is actually expected
> to happen?

Yes.  As on Linux and other systems, there's no default restriction(*)
for the number of processes of an unprivileged user.

Since Cygwin is just a user space DLL in a user space environment,
and given fork() is implemented in terms of Windows' CreateProcess()
call, I'm fairly certain the same will happen in CMD, if you run a
"spawn"-bomb.

> By default Cygwin creates the user environment with unlimited
> processes (and I suppose that any user can just run "bash"
> unrestricted, thus obtaining the unlimited process resource).  Which
> then brings up a question about security of the system, as a whole.
> And so the second part is, is there any way to securely control /
> restrict the behavior?

This is not something controlled by Cygwin, rather by the OS.  Cygwin
provides the POSIX calls getrlimit/setrlimit, but obviously those have
to be implemented in terms of OS functions or faked.

The only implemented limits are RLIMIT_AS, RLIMIT_CORE, RLIMIT_NOFILE
and RLIMIT_STACK, and only RLIMIT_AS is actually calling into the OS to
install a restriction.

I just checked the MSDN man pages and it's possible to install a per-job
process limit.  But that only affects processes inside the job.
Assuming the process limit is established by a shell, only the child
processes inside this shell would be affected, so it's basically
equivalent to a soft limit in the terms of setrlimit.  I don't know of
any way to establish a hard limit in Windows, unless there's something
like a group policy.

Also, the job limit in Windows affects the number of processes, not the
number of threads.  So you can just as well create a limited number of
processes with so many threads that the OS gets dizzy either way.  The
Linux RLIMIT_NPROC restricts the number of threads per user due to the
way threads are implemented.

Looking on Linux, it doesn't really restrict unpriviledged users by
default a lot.  My desktop system has a default hard limit of 95356
processes per user.


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple