On Mon, Jan 11, 2016 at 01:08:56PM -0500, Vlad Yasevich wrote: > On 01/11/2016 11:33 AM, Marcelo Ricardo Leitner wrote: > > On Mon, Jan 11, 2016 at 05:32:10PM +0800, Herbert Xu wrote: > >> David Miller <davem@xxxxxxxxxxxxx> wrote: > >>> From: Eric Dumazet <eric.dumazet@xxxxxxxxx> > >>> Date: Wed, 30 Dec 2015 11:57:31 -0500 > >>> > >>>> I am against using rhashtable in SCTP (or TCP) at this stage, given the > >>>> number of bugs we have with it. > >>> > >>> Come on Eric, we've largely dealt with all of these problems. I haven't > >>> seen a serious report in a while. > >> > >> Well there is still the outstanding issue with softirq insertion > >> potentially failing with ENOMEM if we fail to expand the hash > >> table using just kmalloc. > >> > >> So if the target user does softirq insertions, I would wait until > >> the fix for that is ready. > > > > It does some, yes. If listening socket is not backlogged, there will be > > N inserts at each new association, where N is the number of IP addresses > > that the client is advertising. > > > > This is done on the second stage of the SCTP handshake. Not easily > > DoS-able as it requires receiving a packet from server and replying > > based on it, plus N is limited by MTU. > > How is N limited by MTU? INIT and COOKIE chunks are allowed to exceed > mtu and will be IP fragmented. So it seems that N is limited by 65535-overhead, > where overhead is all the headers plus the sctp cookie info. That can > be quite a lot of addresses. Oups, you're right. One then can trigger quite some inserts with a single new assoc attempt, yes. Marcelo -- 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
