[PATCH] ipv4: ipmr: add socket type checks to ipmr_ioctl()

[PATCH] ipv4: ipmr: add socket type checks to ipmr_ioctl()

[Suchit Karunakaran]

This is the IPv4 counterpart to commit ("ipv6: ip6mr: add socket type
checks to ip6mr_ioctl()") [1].

Similar to the IPv6 issue, ipmr_ioctl() and ipmr_compat_ioctl() access
raw_sk(sk)->ipmr_table without first verifying that the socket is a raw
socket with IPPROTO_IGMP protocol.

This allows a permission bypass where a user with CAP_NET_RAW can create
a non-IGMP raw socket (e.g., IPPROTO_UDP, IPPROTO_TCP, or any other
protocol) and use SIOCGETVIFCNT or SIOCGETSGCNT ioctls to query IPv4
multicast routing statistics. This bypasses the access control that
restricts mroute operations to IGMP sockets only.

Add socket type and protocol checks at the beginning of both
ipmr_ioctl() and ipmr_compat_ioctl() to ensure only IGMP raw sockets
can access multicast routing ioctls.

Signed-off-by: Suchit Karunakaran <suchitkarunakaran@gmail.com>

[1] https://lore.kernel.org/all/20260123011444.2044-2-qikeyu2017@gmail.com/
---
 net/ipv4/ipmr.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index ca9eaee4c2ef..eae03a1b8f66 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1643,6 +1643,10 @@ int ipmr_ioctl(struct sock *sk, int cmd, void *arg)
 	struct sioc_sg_req *sr;
 	struct mr_table *mrt;
 
+	if (sk->sk_type != SOCK_RAW ||
+	    inet_sk(sk)->inet_num != IPPROTO_IGMP)
+		return -EOPNOTSUPP;
+
 	mrt = ipmr_get_table(net, raw_sk(sk)->ipmr_table ? : RT_TABLE_DEFAULT);
 	if (!mrt)
 		return -ENOENT;
@@ -1711,6 +1715,10 @@ int ipmr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
 	struct net *net = sock_net(sk);
 	struct mr_table *mrt;
 
+	if (sk->sk_type != SOCK_RAW ||
+	    inet_sk(sk)->inet_num != IPPROTO_IGMP)
+		return -EOPNOTSUPP;
+
 	mrt = ipmr_get_table(net, raw_sk(sk)->ipmr_table ? : RT_TABLE_DEFAULT);
 	if (!mrt)
 		return -ENOENT;
-- 
2.52.0

Re: [PATCH] ipv4: ipmr: add socket type checks to ipmr_ioctl()

[Eric Dumazet]

On Fri, Jan 23, 2026 at 10:04 AM Suchit Karunakaran
<suchitkarunakaran@gmail.com> wrote:
>
> This is the IPv4 counterpart to commit ("ipv6: ip6mr: add socket type
> checks to ip6mr_ioctl()") [1].
>
> Similar to the IPv6 issue, ipmr_ioctl() and ipmr_compat_ioctl() access
> raw_sk(sk)->ipmr_table without first verifying that the socket is a raw
> socket with IPPROTO_IGMP protocol.
>
> This allows a permission bypass where a user with CAP_NET_RAW can create
> a non-IGMP raw socket (e.g., IPPROTO_UDP, IPPROTO_TCP, or any other
> protocol) and use SIOCGETVIFCNT or SIOCGETSGCNT ioctls to query IPv4
> multicast routing statistics. This bypasses the access control that
> restricts mroute operations to IGMP sockets only.

Where has this been documented? An RFC perhaps ?

This change could break applications if they were unaware of such rules.

I fail to see how querying statistics could be a risk.

What about the RTNL_FAMILY_IPMR rtnetlink interface ? I am sure it is
available to any user.

Re: [PATCH] ipv4: ipmr: add socket type checks to ipmr_ioctl()

[Suchit Karunakaran]

On Fri, 23 Jan 2026 at 14:57, Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Jan 23, 2026 at 10:04 AM Suchit Karunakaran
> <suchitkarunakaran@gmail.com> wrote:
> >
> > This is the IPv4 counterpart to commit ("ipv6: ip6mr: add socket type
> > checks to ip6mr_ioctl()") [1].
> >
> > Similar to the IPv6 issue, ipmr_ioctl() and ipmr_compat_ioctl() access
> > raw_sk(sk)->ipmr_table without first verifying that the socket is a raw
> > socket with IPPROTO_IGMP protocol.
> >
> > This allows a permission bypass where a user with CAP_NET_RAW can create
> > a non-IGMP raw socket (e.g., IPPROTO_UDP, IPPROTO_TCP, or any other
> > protocol) and use SIOCGETVIFCNT or SIOCGETSGCNT ioctls to query IPv4
> > multicast routing statistics. This bypasses the access control that
> > restricts mroute operations to IGMP sockets only.
>
> Where has this been documented? An RFC perhaps ?
>
> This change could break applications if they were unaware of such rules.
>
> I fail to see how querying statistics could be a risk.
>
> What about the RTNL_FAMILY_IPMR rtnetlink interface ? I am sure it is
> available to any user.

Hi Eric. The primary motivations for this patch are the IPv6
counterpart mentioned in the commit message and the commit 5e1859f.