[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

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

[Konstantin Andreev]

Greg KH, Jun 25, 2026:
> 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?

The patches that produced net/core/rtnetlink.c:rtnl_get_peer_net(),
being fixed in 6.18-7.0, are not a refactoring.

Actually, rtnl_get_peer_net() almost literally
replicates the “peer net” management code that can be found
in vxcan_newlink(), netkit_new_link(), and veth_newlink().

These patches are part of a larger new feature series:
"rtnetlink: Convert rtnl_newlink() to per-netns RTNL"
From: Kuniyuki Iwashima, 2024-11-07
Link: https://lore.kernel.org/all/20241108004823.29419-1-kuniyu@amazon.com/

These patches in the series
v
¦     In git log order:
¦
¦   636af13f213b ("rtnetlink: Register rtnl_dellink() and rtnl_setlink() with RTNL_FLAG_DOIT_PERNET_WIP")
¦   d91191ffe23f ("rtnetlink: Convert RTM_NEWLINK to per-netns RTNL")
├─> fefd5d082172 ("netkit: Set IFLA_NETKIT_PEER_INFO to netkit_link_ops.peer_type")
├─> 6b84e558e95d ("vxcan: Set VXCAN_INFO_PEER to vxcan_link_ops.peer_type")
├─> 0eb87b02a705 ("veth: Set VETH_INFO_PEER to veth_link_ops.peer_type")
└─> 28690e5361c0 ("rtnetlink: Add peer_type in struct rtnl_link_ops")
     cbaaa6326bc5 ("rtnetlink: Introduce struct rtnl_nets and helpers")
     68297dbb967f ("rtnetlink: Remove __rtnl_link_register()")
     6b57ff21a310 ("rtnetlink: Protect link_ops by mutex")
     d5ec8d91f82e ("rtnetlink: Remove __rtnl_link_unregister()")

At the time, rtnl_get_peer_net() was named rtnl_add_peer_net().

Having common “peer net” management code in rtnl_get_peer_net()
made it possible to “add missing netlink_ns_capable()”
in a single location.

If the series is to be backported to 6.12.y
then the following commits must be backported as well,
because they fix bugs introduced by that series:

48327566769a ("rtnetlink: fix double call of rtnl_link_get_net_ifla()")
954a2b40719a ("rtnetlink: Try the outer netns attribute in rtnl_get_peer_net()")

Commit-by-commit replication of the evolution of
rtnl_get_peer_net(), vxcan_newlink(), netkit_new_link(),
and veth_newlink() means backporting a new feature,
introducing and fixing bugs.

It seems reasonable to avoid "introduce and fix bugs" roundtrip
during backport, but then we miss commit-by-commit replication.

As we miss replication, we may also discard
the “new feature” commits as well.

Cutting these out leaves us with a targeted re-implementation of
the CVE fix. IMO, that's exactly what Maximilian Heyne's patch does.

Regards,
Konstantin