[PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[Anil Kaushik]

The gtp generic netlink family sends notifications on its "gtp"
multicast group when a PDP context is added or deleted, and for GTP-U
echo responses. They carry the same attributes as a GETPDP reply: the
MS and peer addresses, and the TEIDs, or the TID and the flow label.

GETPDP requires CAP_NET_ADMIN, but generic netlink lets any user join a
multicast group by default, so an unprivileged user in the network
namespace of the gtp device can read all of this.

Fix by marking the group with GENL_MCAST_CAP_NET_ADMIN, like the psample
"packets" group. Only users with CAP_NET_ADMIN in the user namespace
owning the network namespace can then join it.

Tested by joining the group as root, as root without CAP_NET_ADMIN, and
as an unprivileged user:

Before:
  root: joined
  root without CAP_NET_ADMIN: joined
  nobody: joined

After:
  root: joined
  root without CAP_NET_ADMIN: EPERM
  nobody: EPERM

Fixes: 50aba46c234e ("gtp: add notification mechanism")
Signed-off-by: Anil Kaushik <anilkaushikwireless@gmail.com>
---
 drivers/net/gtp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 69fe5717846b..e5ff1621ed62 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -118,7 +118,8 @@ enum gtp_multicast_groups {
 };
 
 static const struct genl_multicast_group gtp_genl_mcgrps[] = {
-	[GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME },
+	[GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME,
+			     .flags = GENL_MCAST_CAP_NET_ADMIN, },
 };
 
 static void pdp_context_delete(struct pdp_ctx *pctx);
-- 
2.25.1

Re: [PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[Anil Kaushik]

On Wed, Oct 21, 2026 at 12:33 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
Found by manual code inspection: GETPDP requires CAP_NET_ADMIN, but the
multicast group that sends the same data did not.
Thanks,
Anil

> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Re: [PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] After this patch, the multicast group and GETPDP carry the
  same PDP-context data but are guarded by different checks.

--

gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

This commit marks the gtp generic netlink "gtp" multicast group with
GENL_MCAST_CAP_NET_ADMIN, so joining it requires CAP_NET_ADMIN in the user
namespace owning the network namespace. The goal is to stop unprivileged
users from reading PDP context notifications that GETPDP restricts to
CAP_NET_ADMIN holders.

> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
> index 69fe5717846b5..e5ff1621ed620 100644
> --- a/drivers/net/gtp.c
> +++ b/drivers/net/gtp.c
> @@ -118,7 +118,8 @@ enum gtp_multicast_groups {
>  };
>  
>  static const struct genl_multicast_group gtp_genl_mcgrps[] = {
> -	[GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME },
> +	[GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME,
> +			     .flags = GENL_MCAST_CAP_NET_ADMIN, },

[Severity: Medium]
Does this make the multicast group check the same as the one on GETPDP?
The commit message says:

  GETPDP requires CAP_NET_ADMIN, but generic netlink lets any user join a
  multicast group by default

All of gtp_genl_ops (NEWPDP, DELPDP, GETPDP doit/dumpit, ECHOREQ) use
GENL_ADMIN_PERM. genl_family_rcv_msg() checks it like this:

net/netlink/genetlink.c:
	if ((op.flags & GENL_ADMIN_PERM) &&
	    !netlink_capable(skb, CAP_NET_ADMIN))
		return -EPERM;

netlink_capable() ends up in netlink_ns_capable(skb, &init_user_ns, cap),
so it needs CAP_NET_ADMIN in the initial user namespace.

genl_bind() checks the new flag against the netns owner instead:

net/netlink/genetlink.c:genl_bind() {
    ...
		if ((grp->flags & GENL_MCAST_CAP_NET_ADMIN) &&
		    !ns_capable(net->user_ns, CAP_NET_ADMIN))
			ret = -EPERM;
    ...
}

Take a gtp device in a netns owned by a non-init user namespace, where an
init-ns daemon installs PDP contexts through GTPA_NET_NS_FD (gtp_find_dev()
calls get_net_ns_by_fd()). gtp_tunnel_notify() multicasts to
dev_net(pctx->dev):

	ret = genlmsg_multicast_netns(&gtp_genl_family, dev_net(pctx->dev), msg,
				      0, GTP_GENL_MCGRP, GFP_ATOMIC);

Root inside that container would get -EPERM from GETPDP and the dump. It
could still join the "gtp" group and receive every NEWPDP, DELPDP and echo
response notification. These carry the MS and peer addresses, the TEIDs,
and the TID and flow label.

When the UDP socket lives in the host netns, container root has no other
way to see the TEIDs and peer addresses.

Genetlink has no init_user_ns scoped GENL_MCAST_* flag. Making the two
checks match would need a core change, or moving the ops to
GENL_UNS_ADMIN_PERM if userns scope is the intended policy.
net/ipv6/ioam6.c already pairs GENL_ADMIN_PERM ops with a
GENL_MCAST_CAP_NET_ADMIN group in the same way.

This patch does block fully unprivileged users. The commit message also
says "in the user namespace owning the network namespace".

Could the commit message say that the multicast check is still weaker than
the GETPDP check?

>  };
>  
>  static void pdp_context_delete(struct pdp_ctx *pctx);

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261021065750.2069795-1-anilkaushikwireless%40gmail.com

Re: [PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[Anil Kaushik]

On Fri, Oct 23, 2026 at 12:28 PM <netdev-bot+sashiko@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] After this patch, the multicast group and GETPDP carry the
>   same PDP-context data but are guarded by different checks.
>
> --
>
> gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group
>
> This commit marks the gtp generic netlink "gtp" multicast group with
> GENL_MCAST_CAP_NET_ADMIN, so joining it requires CAP_NET_ADMIN in the user
> namespace owning the network namespace. The goal is to stop unprivileged
> users from reading PDP context notifications that GETPDP restricts to
> CAP_NET_ADMIN holders.
>
> > diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
> > index 69fe5717846b5..e5ff1621ed620 100644
> > --- a/drivers/net/gtp.c
> > +++ b/drivers/net/gtp.c
> > @@ -118,7 +118,8 @@ enum gtp_multicast_groups {
> >  };
> >
> >  static const struct genl_multicast_group gtp_genl_mcgrps[] = {
> > -     [GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME },
> > +     [GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME,
> > +                          .flags = GENL_MCAST_CAP_NET_ADMIN, },
>
> [Severity: Medium]
> Does this make the multicast group check the same as the one on GETPDP?
> The commit message says:
>
>   GETPDP requires CAP_NET_ADMIN, but generic netlink lets any user join a
>   multicast group by default
>


> All of gtp_genl_ops (NEWPDP, DELPDP, GETPDP doit/dumpit, ECHOREQ) use
> GENL_ADMIN_PERM. genl_family_rcv_msg() checks it like this:
>
> net/netlink/genetlink.c:
>         if ((op.flags & GENL_ADMIN_PERM) &&
>             !netlink_capable(skb, CAP_NET_ADMIN))
>                 return -EPERM;
>
> netlink_capable() ends up in netlink_ns_capable(skb, &init_user_ns, cap),
> so it needs CAP_NET_ADMIN in the initial user namespace.
>
> genl_bind() checks the new flag against the netns owner instead:
>
> net/netlink/genetlink.c:genl_bind() {
>     ...
>                 if ((grp->flags & GENL_MCAST_CAP_NET_ADMIN) &&
>                     !ns_capable(net->user_ns, CAP_NET_ADMIN))
>                         ret = -EPERM;
>     ...
> }
>
> Take a gtp device in a netns owned by a non-init user namespace, where an
> init-ns daemon installs PDP contexts through GTPA_NET_NS_FD (gtp_find_dev()
> calls get_net_ns_by_fd()). gtp_tunnel_notify() multicasts to
> dev_net(pctx->dev):
>
>         ret = genlmsg_multicast_netns(&gtp_genl_family, dev_net(pctx->dev), msg,
>                                       0, GTP_GENL_MCGRP, GFP_ATOMIC);
>
> Root inside that container would get -EPERM from GETPDP and the dump. It
> could still join the "gtp" group and receive every NEWPDP, DELPDP and echo
> response notification. These carry the MS and peer addresses, the TEIDs,
> and the TID and flow label.
>
> When the UDP socket lives in the host netns, container root has no other
> way to see the TEIDs and peer addresses.
>
> Genetlink has no init_user_ns scoped GENL_MCAST_* flag. Making the two
> checks match would need a core change, or moving the ops to
> GENL_UNS_ADMIN_PERM if userns scope is the intended policy.
> net/ipv6/ioam6.c already pairs GENL_ADMIN_PERM ops with a
> GENL_MCAST_CAP_NET_ADMIN group in the same way.
>
> This patch does block fully unprivileged users. The commit message also
> says "in the user namespace owning the network namespace".
>
> Could the commit message say that the multicast check is still weaker than
> the GETPDP check?
>
Right, it should. v2 says it: the group check is still weaker than the
one on GETPDP, as genetlink has no multicast group flag for the initial
user namespace, and this fix blocks the unprivileged users.

pw-bot: cr
> >  };
> >
> >  static void pdp_context_delete(struct pdp_ctx *pctx);
>
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261021065750.2069795-1-anilkaushikwireless%40gmail.com

Re: [PATCH net] gtp: Require 'CAP_NET_ADMIN' when joining the gtp multicast group

[Anil Kaushik]

On Fri, Oct 23, 2026 at 06:58:02AM +0000, netdev-bot+sashiko@kernel.org wrote:
> - [Medium] After this patch, the multicast group and GETPDP carry the
>   same PDP-context data but are guarded by different checks.
[...]
> Could the commit message say that the multicast check is still weaker than
> the GETPDP check?

Right, it should. v2 says it: the group check is still weaker than the
one on GETPDP, as genetlink has no multicast group flag for the initial
user namespace, and this fix blocks the unprivileged users.

pw-bot: cr