On Wed, Apr 28, 2010 at 01:52:05PM -0400, Vlad Yasevich wrote: > > > Vlad Yasevich wrote: > > > > Neil Horman wrote: > >> On Wed, Apr 28, 2010 at 10:00:37AM -0400, Vlad Yasevich wrote: > >>> I have this patch and a few others already queued. > >>> > >>> I was planning on sending these today for stable. > >>> > >>> Here is the full list of stable patches I have: > >>> > >>> sctp: Fix oops when sending queued ASCONF chunks > >>> sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set > >>> sctp: per_cpu variables should be in bh_disabled section > >>> sctp: fix potential reference of a freed pointer > >>> sctp: avoid irq lock inversion while call sk->sk_data_ready() > >>> > >>> -vlad > >>> > >> Are you sure? this oops looks _very_ simmilar to the INIT/INIT-ACK length > >> calculation oops described above, but is in fact different, and requires this > >> patch, from what I can see. The right fix might be in the ASCONF chunk patch > >> you list above, but I don't see that in your tree at the moment, so I can't be > >> sure. > > > > As I said, I totally goofed when reading the description and I apologize. > > However, I do one comment regarding the patch. > > > > If the bad packet is REALLY long (I mean close to 65K IP limit), then > > we'll end up allocating a supper huge skb in this case and potentially exceed > > the IP length limitation. Section 11.4 of rfc 4960 allows us to omit some > > errors and limit the size of the packet. > > > > I would recommend limiting this to MTU worth of potentiall errors. This is > > on top of what the INIT-ACK is going to carry, so at most we'll sent 2 MTUs > > worth. That's still a potential by amplification attack, but it's somewhat > > mitigated. > > > > Of course now we have to handle the case of checking for space before adding > > an error cause. :) > > > > Hi Neil > > I am also not crazy about the pre-allocation scheme. In the case where you have > say 100 parameters that are all 'skip' parameters, you'd end up pre-allocating a > huge buffer for absolutely nothing. > Would have been nice if you'd made your opinion known 4 hours ago when I was testing version 2 of this. :) > This is another point toward a fixed error chunk size and let parameter > processing allocate it when it reaches a parameter that needs an error. > Hmm, ok, what would you say to a pathmtu sized chunk allocation in parameter processing that drops errors beyond its capacity Neil > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
