On 16 January 2018 at 19:00, David Miller <da...@davemloft.net> wrote: > From: Tom Herbert <t...@herbertland.com> > Date: Tue, 16 Jan 2018 09:36:41 -0800 > >> sk_user_data is set with the sk_callback lock held in code below. >> Should be able to take the lock earlier can do this check under the >> lock. > > csock, and this csk, is obtained from an arbitrary one of the > process's FDs. It can be any socket type or family, and that socket's > family might set sk_user_data without the callback lock. > > The only socket type check is making sure it is not another PF_KCM > socket. So that doesn't help with this problem.
Is it the intention to update all socket code over time to write sk_user_data within the sk_callback lock? If so, I'm happy to address that in the l2tp code (and update the kcm patch to check sk_user_data within the sk_callback lock). Or is the preferred solution to restrict KCM to specific socket families, as suggested by Guillaume earlier in the thread?
