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

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

[Maximilian Heyne]

The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.

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

Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:

$ unshare -U -r -n -- bash -c '
  ip link add veth0 type veth peer name foobar netns 1
  sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1

With this patch, it's returning -EPERM.

This fixes CVE-2026-31692

Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
 drivers/net/can/vxcan.c | 5 +++++
 drivers/net/veth.c      | 5 +++++
 2 files changed, 10 insertions(+)

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)) {
+		put_net(peer_net);
+		return -EPERM;
+	}
+
 	peer = rtnl_create_link(peer_net, ifname, name_assign_type,
 				&vxcan_link_ops, tbp, extack);
 	if (IS_ERR(peer)) {
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)) {
+		put_net(net);
+		return -EPERM;
+	}
+
 	peer = rtnl_create_link(net, ifname, name_assign_type,
 				&veth_link_ops, tbp, extack);
 	if (IS_ERR(peer)) {
-- 
2.50.1




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

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

[sashiko-bot]

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