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

[PATCH 5.15.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 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)) {
+		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 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)) {
+		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 5.15.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] 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