netdev - RE: sock_create_kern() and network namespace reference counts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Jan 2017 17:57:29 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Cong Wang' <xiyou.wangcong@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: sock_create_kern() and network namespace reference counts

From: Cong Wang
> Sent: 31 January 2017 17:38
> On Tue, Jan 31, 2017 at 7:41 AM, David Laight <David.Laight@...lab.com> wrote:
> > Commit 26abe1437 changed sock_create_kern() so that it stopped
> > holding a reference to the network namespace.
> > The rational seemed to be 'to allow to stop it' (presumably 'be deleted').
> > Prior to this change some kernel paths used sk_change_net() (etc) to
> > change the namespace after the socket was created.
> >
> > If the socket doesn't hold a reference to the namespace, what actually
> > happens when the namespace is deleted?
> 
> Kernel socket should have the same lifetime with the net namespace,
> that is, created in net_init and released in net_exit. Think about it, if it
> really held a refcnt to this netns, how could this netns be teared down?

That rather depends on what they are being used for.
Consider something like an in kernel ftp client, it doesn't really care
about namespaces except in as much as the connections it creates must
be inside the correct namespace.
The namespace shouldn't be torn down while that connection exists any more
than it should be torn down while a user process has an open connection.
(Listening sockets are likely to be more of a problem.)

We have in kernel code that creates SCTP sockets for M3UA.
There is no way we can find out that something has decided to delete a
namespace and I'd expect the connections to hold the namespace busy.
Prior to deleting the namespace you need to do whatever is necessary
to make the driver delete all its sockets.

Potentially there could be some system call that causes 'error' events
on all the sockets so that the driver code can delete them allowing
the namespace be deleted.

	David