Re: [PATCH 6.12.y] net: add missing ns_capable check for peer netns

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch approximates `netlink_ns_capable()` with `ns_capable()`, leaving the system vulnerable to a Confused Deputy attack via passed netlink sockets.
--

commit 2a12959cedf2cc9c8b0a31fb916efbc1495579b3
Author: Maximilian Heyne <mheyne@amazon.de>

net: add missing ns_capable check for peer netns

This patch attempts to fix CVE-2026-31692 on older stable kernels by
adding capability checks to vxcan, netkit, and veth when creating peer
interfaces. It replaces the upstream netlink_ns_capable() check with
ns_capable(), relying on the synchronous nature of the newlink operation.

> Approximate the netlink_ns_capable check with an ns_capable check. As
> the newlink operation is synchronous this should result in the same
> behavior.

[Severity: Critical]
Does replacing netlink_ns_capable() with ns_capable() leave the system
vulnerable to a Confused Deputy attack, despite the synchronous behavior?

While the newlink operation is synchronous, ns_capable() only checks the
current thread's capabilities. netlink_ns_capable() also checks the
capabilities of the process that originally opened the netlink socket.

If an unprivileged attacker creates a netlink socket, crafts an RTM_NEWLINK
payload to create a peer interface in a privileged namespace, and passes the
socket file descriptor to a privileged SUID binary, could the SUID binary be
tricked into writing the payload? In this scenario, ns_capable() would see
the SUID binary's CAP_NET_ADMIN and allow the operation, bypassing the
intended security boundary since the unprivileged socket creator's
capabilities are ignored.

> diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
> index 9e1b7d41005f8..851c93bf0b310 100644
> --- a/drivers/net/can/vxcan.c
> +++ b/drivers/net/can/vxcan.c
[ ... ]
> @@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
>  	if (IS_ERR(peer_net))
>  		return PTR_ERR(peer_net);
>  
> +	if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
> +		put_net(peer_net);
> +		return -EPERM;
> +	}
> +

[Severity: Critical]
Does this ns_capable() call in vxcan_newlink() introduce the confused
deputy vulnerability described above?

>  	peer = rtnl_create_link(peer_net, ifname, name_assign_type,
>  				&vxcan_link_ops, tbp, extack);
>  	if (IS_ERR(peer)) {

> diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
> index fba2c734f0ec7..e0c42fa0c835c 100644
> --- a/drivers/net/netkit.c
> +++ b/drivers/net/netkit.c
[ ... ]
> @@ -413,6 +413,11 @@ static int netkit_new_link(struct net *src_net, struct net_device *dev,
>  	if (IS_ERR(net))
>  		return PTR_ERR(net);
>  
> +	if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
> +		put_net(net);
> +		return -EPERM;
> +	}
> +

[Severity: Critical]
Does this ns_capable() call in netkit_new_link() introduce the confused
deputy vulnerability described above?

>  	peer = rtnl_create_link(net, ifname, ifname_assign_type,
>  				&netkit_link_ops, tbp, extack);
>  	if (IS_ERR(peer)) {

> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 77e4b0d1ca557..6ffde7ee2119d 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
[ ... ]
> @@ -1854,6 +1854,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
>  	if (IS_ERR(net))
>  		return PTR_ERR(net);
>  
> +	if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
> +		put_net(net);
> +		return -EPERM;
> +	}
> +

[Severity: Critical]
Does this ns_capable() call in veth_newlink() introduce the confused
deputy vulnerability described above?

>  	peer = rtnl_create_link(net, ifname, name_assign_type,
>  				&veth_link_ops, tbp, extack);
>  	if (IS_ERR(peer)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-pats-coif-316245c6@mheyne-amazon?part=1