Bug 23740
| Summary: | kernel DoS tha could be executed by any user | ||
|---|---|---|---|
| Product: | Base System | Reporter: | iasenkk <iasenkk> |
| Component: | kern | Assignee: | silby |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed Yet Another Fork Bomb PR. 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 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 ! 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. 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?
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 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..) Responsible Changed From-To: freebsd-bugs->roam roam was working on this one Responsible Changed From-To: roam->silby I have this almost tackled, an effective fix will appear in the tree soon. State Changed From-To: analyzed->closed 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. |
int main() { while(1) fork(); return(1); } it produces kernel panic (kernel resources exhausted) Fix: just report for now How-To-Repeat: int main() { while(1) fork(); return(1); } compile and run