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-next>] [day] [month] [year] [list]
Date:   Tue, 31 Jan 2017 15:41:23 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: sock_create_kern() and network namespace reference counts

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?
I can't help feeling there is an indirection through a stale pointer
just waiting to happen.

Clearly the driver calling sock_create_kern() could itself call get_net()
but that could still leave issues with sockets that get into TIME_WAIT
states.
Even that is easier said than done, a non-GPL driver cannot call put_net()
to drop a reference.

While I can imagine that there are some 'special' sockets that don't
need to hold the reference, it seems unlikely that it is true for all
users of sock_create_kern().

	David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ