On Mon, Jan 12, 2026 at 04:52:31PM -0800, Bobby Eshleman wrote:
On Mon, Jan 12, 2026 at 03:34:31PM -0800, Bobby Eshleman wrote:
On Sun, Jan 11, 2026 at 01:43:37AM -0500, Michael S. Tsirkin wrote:
> On Tue, Dec 23, 2025 at 04:28:36PM -0800, Bobby Eshleman wrote:
> > From: Bobby Eshleman <[email protected]>
> >
> > Add netns logic to vsock core. Additionally, modify transport hook
> > prototypes to be used by later transport-specific patches (e.g.,
> > *_seqpacket_allow()).
> >
> > Namespaces are supported primarily by changing socket lookup functions
> > (e.g., vsock_find_connected_socket()) to take into account the socket
> > namespace and the namespace mode before considering a candidate socket a
> > "match".
> >
> > This patch also introduces the sysctl /proc/sys/net/vsock/ns_mode to
> > report the mode and /proc/sys/net/vsock/child_ns_mode to set the mode
> > for new namespaces.
> >
> > Add netns functionality (initialization, passing to transports, procfs,
> > etc...) to the af_vsock socket layer. Later patches that add netns
> > support to transports depend on this patch.
> >
> > dgram_allow(), stream_allow(), and seqpacket_allow() callbacks are
> > modified to take a vsk in order to perform logic on namespace modes. In
> > future patches, the net will also be used for socket
> > lookups in these functions.
> >
> > Signed-off-by: Bobby Eshleman <[email protected]>
>
> ...
>
>
> >  static int __vsock_bind_connectible(struct vsock_sock *vsk,
> >                                   struct sockaddr_vm *addr)
> >  {
> > +     struct net *net = sock_net(sk_vsock(vsk));
> >       static u32 port;
> >       struct sockaddr_vm new_addr;
> >
>
>
> Hmm this static port gives me pause. So some port number info leaks
> between namespaces. I am not saying it's a big security issue
> and yet ... people expect isolation.

Probably the easiest solution is making it per-ns, my quick rough draft
looks like this:

diff --git a/include/net/netns/vsock.h b/include/net/netns/vsock.h
index e2325e2d6ec5..b34d69a22fa8 100644
--- a/include/net/netns/vsock.h
+++ b/include/net/netns/vsock.h
@@ -11,6 +11,10 @@ enum vsock_net_mode {

 struct netns_vsock {
        struct ctl_table_header *sysctl_hdr;
+
+       /* protected by the vsock_table_lock in af_vsock.c */
+       u32 port;
+
        enum vsock_net_mode mode;
        enum vsock_net_mode child_ns_mode;
 };
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 9d614e4a4fa5..cd2a47140134 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -748,11 +748,10 @@ static int __vsock_bind_connectible(struct vsock_sock 
*vsk,
                                    struct sockaddr_vm *addr)
 {
        struct net *net = sock_net(sk_vsock(vsk));
-       static u32 port;
        struct sockaddr_vm new_addr;

-       if (!port)
-               port = get_random_u32_above(LAST_RESERVED_PORT);
+       if (!net->vsock.port)
+               net->vsock.port = get_random_u32_above(LAST_RESERVED_PORT);

        vsock_addr_init(&new_addr, addr->svm_cid, addr->svm_port);

@@ -761,11 +760,11 @@ static int __vsock_bind_connectible(struct vsock_sock 
*vsk,
                unsigned int i;

                for (i = 0; i < MAX_PORT_RETRIES; i++) {
-                       if (port == VMADDR_PORT_ANY ||
-                           port <= LAST_RESERVED_PORT)
-                               port = LAST_RESERVED_PORT + 1;
+                       if (net->vsock.port == VMADDR_PORT_ANY ||
+                           net->vsock.port <= LAST_RESERVED_PORT)
+                               net->vsock.port = LAST_RESERVED_PORT + 1;

-                       new_addr.svm_port = port++;
+                       new_addr.svm_port = net->vsock.port++;

                        if (!__vsock_find_bound_socket_net(&new_addr, net)) {
                                found = true;




Another option being to follow inet's path and use
siphash_4u32() the way that secure_ipv4_port_ephemeral() does...


Yeah, I was going to ask what inet does, also because I don't really like the code we have now (not your fault at all).

But maybe is too out of scope to resolve in this series, so I guess just moving what we have per-ns LGTM for now!

Stefano


Reply via email to