Re: [PATCH 5.15.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:
- [High] Approximating `netlink_ns_capable()` with `ns_capable()` introduces a confused deputy vulnerability by omitting the netlink socket opener credential check.
--

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

net: add missing ns_capable check for peer netns

This commit attempts to fix CVE-2026-31692 by approximating
netlink_ns_capable() with ns_capable() directly in the vxcan and veth
interface types, as the upstream fix doesn't apply cleanly to older stable
kernels.

> diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
> index afd9060c5421c..8a61011fdaeef 100644
> --- a/drivers/net/can/vxcan.c
> +++ b/drivers/net/can/vxcan.c
> @@ -198,6 +198,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)) {

[Severity: High]
Does approximating netlink_ns_capable() with ns_capable() here introduce a
confused deputy vulnerability?

netlink_ns_capable() ensures that both the opener of the netlink socket and
the current sender have the required capability. By directly using
ns_capable() in vxcan_newlink(), the netlink socket opener credential check
appears to be bypassed.

Could an unprivileged attacker open a netlink socket, connect it, and trick
a privileged SUID process into writing a crafted RTM_NEWLINK payload to it?

Since the SUID process performs the write, ns_capable() would see the
privileged credentials and succeed, potentially allowing the unprivileged
attacker to bypass the security fix and create devices in arbitrary
privileged network namespaces.

> +		put_net(peer_net);
> +		return -EPERM;
> +	}
> +
>  	peer = rtnl_create_link(peer_net, ifname, name_assign_type,
>  				&vxcan_link_ops, tbp, extack);

[ ... ]

> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index cfacf8965bc59..c644d59d70900 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -1664,6 +1664,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)) {

[Severity: High]
Does this ns_capable() check in veth_newlink() have the same confused
deputy vulnerability as the one in vxcan_newlink(), allowing a bypass of
the socket opener credential check?

> +		put_net(net);
> +		return -EPERM;
> +	}
> +
>  	peer = rtnl_create_link(net, ifname, name_assign_type,
>  				&veth_link_ops, tbp, extack);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-forgot-manic-27dda774@mheyne-amazon?part=1