Re: [PATCH net] l2tp: send netlink notifications in the tunnel's net namespace
Simon Horman <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Aug 09, 2026 at 05:42:52PM +0800, Maoyi Xie wrote:
> l2tp_tunnel_notify() and l2tp_session_notify() use
> genlmsg_multicast_allns(), which delivers to listeners in every network
> namespace. l2tp is per-namespace, and a tunnel records the namespace it
> belongs to in tunnel->l2tp_net. Each event concerns one namespace, yet
> every namespace is told about it. A tunnel event carries the tunnel and
> peer tunnel ids, plus the socket's addresses with both ports for a UDP
> tunnel. A session event carries the session and peer session ids, the
> interface name, plus the L2TP cookies where those are set. A listener
> needs no privilege for any of this, because l2tp_multicast_group[]
> carries no flags and genl_bind() asks for no capability.
>
> The fix is to send to the tunnel's namespace with
> genlmsg_multicast_netns(). Commit 134e63756d5f ("genetlink: make netns
> aware") added both helpers and drew the line between them. The netns
> variant is for an object that lives in a namespace.
>
> I found this by auditing the tree's six genlmsg_multicast_allns() call
> sites for objects that live in a network namespace. Only the two l2tp
> ones do.
>
> I reproduced it on net at dd057113ac7b, in a virtual machine, with no
> real hardware involved. A process in the initial namespace, running as
> an ordinary user with an empty capability set, receives the create and
> delete events of a tunnel. The tunnel was set up inside an unprivileged
> user and network namespace. tools/testing/selftests/net/l2tp.sh passes
> before and after.
>
> On a container host, any local user and every other tenant can read a
> tenant's tunnel parameters.
>
> Fixes: 33f72e6f0c67 ("l2tp : multicast notification to the registered listeners")
> Cc: [email protected]
> Signed-off-by: Maoyi Xie <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
FTR, I don't think the issues flagged by Sashiko [1] should
block progress of this patch. But you may want to look into
them in the context of possible follow-up.
[1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260809094252.2107242-1-maoyixie.tju%40gmail.com