From nobody@FreeBSD.org  Thu Dec 21 17:18:21 2000
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id B4CEE37B404
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 21 Dec 2000 17:18:21 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id eBM1ILd58673;
	Thu, 21 Dec 2000 17:18:21 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200012220118.eBM1ILd58673@freefall.freebsd.org>
Date: Thu, 21 Dec 2000 17:18:21 -0800 (PST)
From: iasenkk@hotmail.com
Sender: nobody@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org
Subject: kernel DoS tha could be executed by any user
X-Send-Pr-Version: www-1.0

>Number:         23740
>Category:       kern
>Synopsis:       kernel DoS tha could be executed by any user
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    silby
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 21 17:20:01 PST 2000
>Closed-Date:    Wed Mar 6 20:52:55 PST 2002
>Last-Modified:  Wed Mar 06 20:54:45 PST 2002
>Originator:     Iasen Kostoff
>Release:        4.2
>Organization:
>Environment:
FreeBSD HellRaZoR.tbyte.org 4.2-RELEASE FreeBSD 4.2-RELEASE #2: Wed Dec 20 02:13:45 EET 20
00     root@HellRaZoR.tbyte.org:/usr/src/sys/compile/TQONIX4  i386
>Description:
int main()
{
     while(1) fork();
     return(1);
}
it produces kernel panic (kernel resources exhausted)
>How-To-Repeat:
int main()
{
     while(1) fork();
     return(1);
}
compile and run
>Fix:
just report for now

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: des 
State-Changed-When: Fri Dec 22 01:19:45 PST 2000 
State-Changed-Why:  
Yet Another Fork Bomb PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23740 

From: Dag-Erling Smorgrav <des@ofug.org>
To: iasenkk@hotmail.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/23740: kernel DoS tha could be executed by any user
Date: 22 Dec 2000 10:20:56 +0100

 iasenkk@hotmail.com writes:
 > int main()
 > {
 >      while(1) fork();
 >      return(1);
 > }
 > it produces kernel panic (kernel resources exhausted)
 
 That's what resource limits are for. 'man login.conf'.
 
 DES
 -- 
 Dag-Erling Smorgrav - des@ofug.org
 

From: Charlie Root <iasenkk@hotmail.com>
To: freebsd-gnats-submit@FreeBSD.org, iasenkk@hotmail.com
Cc:  
Subject: Re: kern/23740: kernel DoS tha could be executed by any user
Date: Fri, 22 Dec 2000 11:45:27 +0200

 I don't think that is the way it should be done (login.conf)
 The kernel shoul have its own protection ! Even agains super user. He
 can do something wrong and it will break up the whole system. I mean it
 because the kernel in one of my experiments coulnd not even reboot . It
 said "panic" and that was all no syncing no auto reboot !
 
 

From: Charlie Root <iasenkk@hotmail.com>
To: freebsd-gnats-submit@FreeBSD.org, iasenkk@hotmail.com
Cc:  
Subject: Re: kern/23740: kernel DoS tha could be executed by any user
Date: Fri, 22 Dec 2000 11:59:35 +0200

 Addon :)
 
 I think that the kernel should not execute "panic" but to manage some
 how with the problem.
 And also I think it's not just fork problem , but "memory allocation" or
 "user limits check" problem.
 
 
 

From: Peter Pentchev <roam@orbitel.bg>
To: Charlie Root <iasenkk@hotmail.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/23740: kernel DoS tha could be executed by any user
Date: Fri, 22 Dec 2000 12:08:46 +0200

 On Fri, Dec 22, 2000 at 02:00:01AM -0800, Charlie Root wrote:
 > The following reply was made to PR kern/23740; it has been noted by GNATS.
 > 
 > From: Charlie Root <iasenkk@hotmail.com>
 > To: freebsd-gnats-submit@FreeBSD.org, iasenkk@hotmail.com
 > Cc:  
 > Subject: Re: kern/23740: kernel DoS tha could be executed by any user
 > Date: Fri, 22 Dec 2000 11:59:35 +0200
 > 
 >  Addon :)
 >  
 >  I think that the kernel should not execute "panic" but to manage some
 >  how with the problem.
 >  And also I think it's not just fork problem , but "memory allocation" or
 >  "user limits check" problem.
 
 Uhm - "user limits check" problem?  Right on!  So you think the kernel
 should enforce some kind of limits - you're exactly right.  There should
 be a way to tell it what to do, what limits to impose on what users,
 now wouldn't that be a nice idea!  Uh.. wait.. it already does that..
 man 5 login.conf :)
 
 How exactly do you expect the kernel to know which limits to impose
 on what users 'by itself'?  login.conf *is* the way to tell it.
 
 G'luck,
 Peter
 
 -- 
 Hey, out there - is it *you* reading me, or is it someone else?
 

From: Charlie Root <iasenkk@hotmail.com>
To: freebsd-gnats-submit@FreeBSD.org, iasenkk@hotmail.com
Cc:  
Subject: Re: kern/23740: kernel DoS tha could be executed by any user
Date: Fri, 22 Dec 2000 12:31:54 +0200

 OK for user limits let it be so , but memory allocation ?
 And FreeBSD 4.0 doesn't do it that way (just table is full or some
 thing) and nothing more
 no panic no lockups that could beak up your file system.
 
 
State-Changed-From-To: closed->analyzed 
State-Changed-By: roam 
State-Changed-When: Tue Dec 26 03:13:42 PST 2000 
State-Changed-Why:  
As several people pointed out, this *is* a problem - a resource shortage 
should not cause a kernel panic.  I have so far traced it to the good old 
maxusers=128 problem; I'll do some more tests to isolate a minimal test 
case, and then unleash this PR unto the unsuspecting world. 

(I hereby officially proclaim my lack of life - just like Michael C. Wu 
(keichii) described himself in a posting to -arch, I analyzed this issue 
between 1 and 5am in the cold winter morning of Dec 25..) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23740 
Responsible-Changed-From-To: freebsd-bugs->roam 
Responsible-Changed-By: alex 
Responsible-Changed-When: Tue May 29 05:35:37 PDT 2001 
Responsible-Changed-Why:  
roam was working on this one 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23740 
Responsible-Changed-From-To: roam->silby 
Responsible-Changed-By: silby 
Responsible-Changed-When: Mon Feb 11 23:53:58 PST 2002 
Responsible-Changed-Why:  
I have this almost tackled, an effective fix will appear in the tree soon. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23740 
State-Changed-From-To: analyzed->closed 
State-Changed-By: silby 
State-Changed-When: Wed Mar 6 20:52:55 PST 2002 
State-Changed-Why:  
The base problem here was that with a large maxproc value, 
processes will cause all kmaps to be exhausted and a panic 
will ensue. 

One simple way to avoid this problem is to keep maxusers <= 
the MB of ram in your system.  As people may exceed this setting 
for other reasons, I have added changes so that maxproc 
will not be allowed to grow large enough to cause panics. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23740 
>Unformatted:
