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

[PATCH 6.12.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/netkit.c    | 5 +++++
 drivers/net/veth.c      | 5 +++++
 3 files changed, 15 insertions(+)

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;
+	}
+
 	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;
+	}
+
 	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;
+	}
+
 	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.12.y] net: add missing ns_capable check for peer netns

[Greg KH]

On Wed, Jun 17, 2026 at 08:25:31AM +0000, Maximilian Heyne wrote:
> 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.

Why can't we take the full series of patches instead?  Otherwise this is
going to be a pain over time for any other fixes/updates in this area,
right?

And if not, then we need acks from the maintainers here...

thanks,

greg k-h

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

[Maximilian Heyne]

Hi Greg,

On Thu, Jun 25, 2026 at 12:37:31PM +0100, Greg KH wrote:
> On Wed, Jun 17, 2026 at 08:25:31AM +0000, Maximilian Heyne wrote:
> > 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.
> 
> Why can't we take the full series of patches instead?  Otherwise this is
> going to be a pain over time for any other fixes/updates in this area,
> right?

Agree that this would be a pain. The issue is that this requires to
backport >10 patches. I think for 6.12 it would be like 15 patches so
that each patch doesn't need to be reworked too much.

The reason for me submitting this was that it's easily backports to all
stable kernels. I haven't tested for 6.6 or earlier how many patches
would need to be backported.

I can try to post the series for 6.12 after some more testing (after my
vacation) but I'm think I won't succeed backporting the refactoring
patches back to, say, 5.10.

> 
> And if not, then we need acks from the maintainers here...

So for the backports to older stable kernels we might need this.

Links:
- 6.6.y backport: https://lore.kernel.org/all/20260617-sprain-dye-86c242ac@mheyne-amazon/
- 6.1.y backport: https://lore.kernel.org/all/20260617-keyed-dude-3493dbdb@mheyne-amazon/
- 5.15.y backport: https://lore.kernel.org/all/20260617-forgot-manic-27dda774@mheyne-amazon/
- 5.10.y backport: https://lore.kernel.org/all/20260617-thaws-enid-af4ad67d@mheyne-amazon/

Regards,

Maximilian

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

[Greg KH]

On Fri, Jul 10, 2026 at 12:49:54PM +0000, Maximilian Heyne wrote:
> Hi Greg,
> 
> On Thu, Jun 25, 2026 at 12:37:31PM +0100, Greg KH wrote:
> > On Wed, Jun 17, 2026 at 08:25:31AM +0000, Maximilian Heyne wrote:
> > > 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.
> > 
> > Why can't we take the full series of patches instead?  Otherwise this is
> > going to be a pain over time for any other fixes/updates in this area,
> > right?
> 
> Agree that this would be a pain. The issue is that this requires to
> backport >10 patches. I think for 6.12 it would be like 15 patches so
> that each patch doesn't need to be reworked too much.

15 is trivial, we have taken hundreds in the past :)

> The reason for me submitting this was that it's easily backports to all
> stable kernels. I haven't tested for 6.6 or earlier how many patches
> would need to be backported.
> 
> I can try to post the series for 6.12 after some more testing (after my
> vacation) but I'm think I won't succeed backporting the refactoring
> patches back to, say, 5.10.

Full series is best because maintaining this over time will be easier if
you do that, not harder.

thanks,

greg k-h