From: Marcelo Ricardo Leitner > Sent: 10 September 2015 13:54 > Em 09-09-2015 21:16, David Miller escreveu: > > From: Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> > > Date: Wed, 9 Sep 2015 17:03:01 -0300 > > > >> So the fix then is to invert the initialization order inside > >> register_pernet_subsys() so that the control socket is created by last > >> and also block socket creation if netns initialization wasn't yet > >> performed. > > > > If we really need to we could make ->create() fail with -EAFNOSUPPORT > > if kern==1 until the protocol is fully setup. > > > > Or, instead of failing, we could make such ->create() calls block > > until the control sock init is complete or fails. > > I guess I should have written that paragraph in another order, perhaps like: > So the fix then is to deny any sctp socket creation until netns > initialization is sufficiently done. And due to that, we have to > initialize the control socket as last step in netns initialization, as > now it can't be created earlier anymore. > > Is it clearer on the intention? > > And my emphasis on userspace sockets was to highlight that a random user > could trigger it, but yes both users are affected by the issue. > > Strictly speaking, we would have to block ->create() not until the > control socket init is done but until the protocol is fully loaded. Such > condition, with this patch, is after net->sctp.auto_asconf_splist is > initialized. But for blocking until instead of just denying, we would > need some other mechanism. > > It would be better from the (sctp) user point of view but then such > solution may better belong to another layer instead and protect all > protocols at once. (I checked and couldn't find other protocols at risk > like sctp) Given that the first ->create() blocks while the protocol code loads it really wouldn't be right to error a subsequent ->create() because the load hasn't completed. I hold a semaphore across sock_create_kern() because of issues with sctp. (Current kernels are nowhere near as bad as really old ones though.) David -- 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
