Date: Fri, 5 Apr 2002 12:44:09 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: bmah@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <15533.57961.725030.692387@grasshopper.cs.duke.edu> In-Reply-To: <3CADE0E7.ED472650@mindspring.com> References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > Andrew Gallatin wrote: > > The problem is that ip_maxfragpackets is: > > "Maximum number of IPv4 fragment reassembly queue entries" > > > > You (& I, & most people probably) took that number to mean the cap on > > the number of mbufs sitting on reassembly queues. However, its really > > a cap on the number of fragmented packets sitting on reassembly > > queues: > > [ ... ] > > > Since the linux host is sending 16K packets, that means that each > > packet is made up of 11 cluster mbufs (assuming a 1500 byte mtu). > > There can be as many as 10 cluster mbufs on the reassembly queue for > > for each packet. > > > > Lets say we have 2048 cluster mbufs. That makes maxfragpackets 512. > > However, 512 * 10 mbufs = 5120 mbufs. Oops. > > > > I think the limit should probably be something much smaller, like > > maybe nmbclusters / (net.inet.udp.recvspace / 1472). Or the > > implementation & name should be changed to "maxfragmbufs" > > > This suggests that one could fragment as large a UDP packet > as one chooses into "n" fragments, and then supply only "n-1" > elements of the whole packet, as an attack, in order to use > up system resources. Essentially what a linux NFS client is already doing.. ;-( > I think we are better off with my suggestion, where udp packets > above a certain size are intentionally dropped as "not supported". Depending on what the "certain size" is, that might be reasonable. > Alternately, it would be a good idea to have a "ip_maxpacketfrags" > instead of an "ip_maxfragpackets", to put a hard limit on the > number of mbufs that can be consumed by the fragment reassembly > process. I think this is the best solution. > Of course, this also suggests that using TCP instead of UDP for > the NFS would result in the problem "just going away", for the > original poster, which is probably all the opriginal poster > really cares about... Considering that a modern linux NFS client is going to be a common scenario, we should probably be able to interroperate with it, no matter how broken its defaults are. BTW, 16K UDP packets are legal according to the NFS V3 spec, if I remember it correctly. Drew 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?15533.57961.725030.692387>