Date: Fri, 05 Apr 2002 09:37:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: bmah@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I think we are better off with my suggestion, where udp packets above a certain size are intentionally dropped as "not supported". 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. 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... -- Terry 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?3CADE0E7.ED472650>