Date: Tue, 7 Sep 1999 07:58:28 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Matthew Dillon <dillon@apollo.backplane.com>, Bosko Milekic <bmilekic@dsuper.net> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations Message-ID: <199909071458.HAA00426@salsa.gv.tsc.tdk.com> In-Reply-To: Matthew Dillon <dillon@apollo.backplane.com> "Re: mbuf shortage situations" (Sep 5, 9:18pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 5, 9:18pm, Matthew Dillon wrote: } Subject: Re: mbuf shortage situations } : The only reason that I see for which we would actually panic() in } :this situation (as opposed to suffer the packet loss) is if we get to the } :point where we're losing packets because some script kid starts up } :something that will eat up sockbuf space and continuously fork, then we } :would lose all remote access to the machine in question (since all packets } :would be dropped) and we wouldn't really mind a panic() for obvious } :practical reasons. Well, I really would mind the panic(). } : In any case, I, personally, would prefer to suffer packet loss as } :opposed to a panic (especially now that Brian is in the process of writing } :diffs that will allow us to limit socket buffer space per UID through } :login.conf!) } : Having MGET store that null (e.g. fail as opposed to panic) on a } :M_WAIT seems fairly easy to fix, and would probably require some patching } :that would ensure that the packet loss is handeled relatively 'cleanly' } :(probably some debugging), but I wouldn't mind doing this. However, I'd } :like to know if there are objections to doing this or, in fact, if there } :are any suggestions on how to handle mbuf shortage situations (aside from } :just limiting -- although limiting is in itself a good solution and I'm } :glad that Brian F. is working on that). At least historically most of the panics have been caused by the code not properly checking the result of the MGET and dereferencing a NULL pointer. Any of those that are still in the code need to be fixed. My impression is that for reasonably recent versions of FreeBSD this attack doesn't panic the machine but just wedges the network system due to mbuf exhaustion. The problem is that if you get to this point you're basically hosed. It's OK to toss packets that you receive from the net as long as you haven't sent an ack for them, toss outgoing UDP packets, and block writes to stream sockets, but you can't toss acked TCP packets that you've received, or the data queued to a stream socket by write(). This particular attack does the latter, so the only possible fix is to prevent all the mbufs from being consumed by it in the first place. } The issue is basically having someone find the time to figure out } how to gracefully unwind various pieces of network code when an } mbuf cannot be allocated. Once that is done, the panic can be } turned into a (rate-limited) printf. That won't help. All that does is keep a root spinning on a failed syscall instead of blocking on MGET when he's trying to log in to kill the errant process. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909071458.HAA00426>