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

[Konstantin Andreev <andreev@swemel.ru>]

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