Re: [PATCH 6.6.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] Using `ns_capable()` instead of `netlink_ns_capable()` bypasses file descriptor capability checks, leaving the kernel vulnerable to confused deputy privilege escalation attacks via netlink fd passing.
--

commit 7cb10271bfe1888c97bd5ddcadbd3ed1e69fb9b0
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 the 
netlink_ns_capable() check with ns_capable() directly in the respective 
interface types. It assumes that because the newlink operation is 
synchronous, this will result in the same behavior.

> diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
> index 98c669ad51414..da4affff65476 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)) {

[Severity: High]
Does using ns_capable() instead of netlink_ns_capable() leave the kernel
vulnerable to confused deputy attacks via file descriptor passing?

Because ns_capable() only evaluates current_cred(), an unprivileged
attacker could create a netlink socket, craft an RTM_NEWLINK payload,
and pass the socket fd (e.g., via SCM_RIGHTS) to a privileged process.
When the privileged deputy writes to the socket, this ns_capable() check
would succeed using the deputy's credentials, ignoring the fact that the
socket was opened by an unprivileged user.

netlink_ns_capable() explicitly checks both the socket opener
(file_ns_capable) and the sender (ns_capable) to prevent exactly this
scenario. Could this approach be revised to ensure the socket opener's
credentials are also verified?

> +		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 2b3b0beb55c88..ba4ca6c6bc9d8 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -1857,6 +1857,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]
Would this ns_capable() check in veth_newlink() similarly bypass the
socket opener credential check?

As with vxcan_newlink(), using ns_capable() alone seems to bypass the
file descriptor capability checks that netlink_ns_capable() provides,
potentially allowing privilege escalation if the netlink fd is passed
to a more privileged process.

> +		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-sprain-dye-86c242ac@mheyne-amazon?part=1