On Tue, Feb 03, 2026 at 04:46:56PM +0100, Bastian Blank wrote:
> On Sat, Dec 27, 2025 at 08:46:49PM -0700, Greg Dahlman wrote:
> > **vsock exists in the global namespace** - Unlike "af_inet" sockets,
> > vsock connections are not bound to a particular network namespace.
> > By default they are visible to every namespace on the host.
>
> Every address family in Linux needs to implement it's own namespace
> handling. In 2007, all existing address families got a check to only
> allow the inital network namespace. af_vsock is newer and never got
> this check.
>
> Every point after the first one is just a result, not a cause.
>
> So a fix would be something like that (untested, no time right now):
>
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -2553,6 +2553,9 @@ static int vsock_create(struct net *net, struct socket
> *sock,
> if (protocol && protocol != PF_VSOCK)
> return -EPROTONOSUPPORT;
>
> + if (!net_eq(net, &init_net))
> + return -EAFNOSUPPORT;
> +
> switch (sock->type) {
> case SOCK_DGRAM:
> sock->ops = &vsock_dgram_ops;
Brad Spengler pointed me at this Linux merge commit (it's not in 6.19,
should get into 6.20):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=099ca4121ea747acc8a0d36852f2f477943f306d
commit 099ca4121ea747acc8a0d36852f2f477943f306d
Merge: 3eef6c061f97 b3b7b33264c6
Author: Paolo Abeni <[email protected]>
Date: Tue Jan 27 10:45:40 2026 +0100
Merge branch 'vsock-add-namespace-support-to-vhost-vsock-and-loopback'
Bobby Eshleman says:
====================
vsock: add namespace support to vhost-vsock and loopback
This series adds namespace support to vhost-vsock and loopback. It does
not add namespaces to any of the other guest transports (virtio-vsock,
hyperv, or vmci).
The current revision supports two modes: local and global. Local
mode is complete isolation of namespaces, while global mode is complete
sharing between namespaces of CIDs (the original behavior).
The mode is set using the parent namespace's
/proc/sys/net/vsock/child_ns_mode and inherited when a new namespace is
created. The mode of the current namespace can be queried by reading
/proc/sys/net/vsock/ns_mode. The mode can not change after the namespace
has been created.
Modes are per-netns. This allows a system to configure namespaces
independently (some may share CIDs, others are completely isolated).
This also supports future possible mixed use cases, where there may be
namespaces in global mode spinning up VMs while there are mixed mode
namespaces that provide services to the VMs, but are not allowed to
allocate from the global CID pool (this mode is not implemented in this
series).
Additionally, added tests for the new namespace features:
tools/testing/selftests/vsock/vmtest.sh
1..25
ok 1 vm_server_host_client
ok 2 vm_client_host_server
ok 3 vm_loopback
ok 4 ns_host_vsock_ns_mode_ok
ok 5 ns_host_vsock_child_ns_mode_ok
ok 6 ns_global_same_cid_fails
ok 7 ns_local_same_cid_ok
ok 8 ns_global_local_same_cid_ok
ok 9 ns_local_global_same_cid_ok
ok 10 ns_diff_global_host_connect_to_global_vm_ok
ok 11 ns_diff_global_host_connect_to_local_vm_fails
ok 12 ns_diff_global_vm_connect_to_global_host_ok
ok 13 ns_diff_global_vm_connect_to_local_host_fails
ok 14 ns_diff_local_host_connect_to_local_vm_fails
ok 15 ns_diff_local_vm_connect_to_local_host_fails
ok 16 ns_diff_global_to_local_loopback_local_fails
ok 17 ns_diff_local_to_global_loopback_fails
ok 18 ns_diff_local_to_local_loopback_fails
ok 19 ns_diff_global_to_global_loopback_ok
ok 20 ns_same_local_loopback_ok
ok 21 ns_same_local_host_connect_to_local_vm_ok
ok 22 ns_same_local_vm_connect_to_local_host_ok
ok 23 ns_delete_vm_ok
ok 24 ns_delete_host_ok
ok 25 ns_delete_both_ok
SUMMARY: PASS=25 SKIP=0 FAIL=0
Thanks again for everyone's help and reviews!
Suggested-by: Sargun Dhillon <[email protected]>
Signed-off-by: Bobby Eshleman <[email protected]>
v15:
https://lore.kernel.org/r/[email protected]
v14:
https://lore.kernel.org/r/[email protected]
v13:
https://lore.kernel.org/all/[email protected]/
v12:
https://lore.kernel.org/r/[email protected]
v11:
https://lore.kernel.org/r/[email protected]
v10:
https://lore.kernel.org/r/[email protected]
v9:
https://lore.kernel.org/all/[email protected]
v8:
https://lore.kernel.org/r/[email protected]
v7:
https://lore.kernel.org/r/[email protected]
v6:
https://lore.kernel.org/r/[email protected]
v5:
https://lore.kernel.org/r/[email protected]
v4:
https://lore.kernel.org/r/[email protected]
v2:
https://lore.kernel.org/kvm/[email protected]
v1: https://lore.kernel.org/r/[email protected]
====================
Link:
https://patch.msgid.link/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
Brad's comments on it are:
https://x.com/spendergrsec/status/2021929584384438428
Feb 12
Looks like the defaults (global for both ns_mode/child_ns_mode) keep everything
working the same as currently, doesn't seem like it'd restrict anything under
unpriv userns as nothing stops changing child_ns_mode back to global after
first setting it to local.
Feb 14
Same things I noticed:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=36e838630c111a510f47e49d559bd26aba7d9a1b
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6a997f38bdf822d4c5cc10b445ff1cb26872580a
Feb 16
The design of this whole thing actually seems to me entirely broken and
useless, especially for something that took 7 years to land. If you want any
kind of reasonable legit use of vsock with this, you're forced into
global/global mode that allows all the unreasonable things.
The local mode also forcing local id allocation is the main aspect making it
unusable (and unfixable later, unless I'm missing something). If at least the
id allocation were global, then you could implement some reasonable
directional/cap-based policies...
but not when you can't even see what you should be able to connect to
(especially so when the same id can be reused by local mode containers).
The referenced netdev commits made on Feb 13 fix issues with the
initially merged implementation, and aren't yet in Linus' tree.
> But I have a question: why do you name sshd, while every AF_VSOCK
> listener is affected?
I assume you're asking Greg - CC'ing.
Alexander
